Publication granted for ECOOP 2000 purposes
|
|
- Hector Bond
- 5 years ago
- Views:
Transcription
1 Position paper: Instrumentation aspects require symmetric join points Lutz Dominick Siemens AG, Corporate Technology, ZT SE 2 D Munich, Germany Lutz.Dominick@mchp.siemens.de March 2000 Publication granted for ECOOP 2000 purposes Abstract This paper presents some of the experiences made with AOP and AspectJ. They got employed for supporting an existing tool for testing and monitoring of distributed systems (TOMDIS). Reusable aspects were defined to attach the Java instrumentation library to application code efficiently and at minimal costs. Some instrumentation requirements, the aspects and their implementation in AspectJ are presented. Not all requirements have been fulfilled by the aspect implementations because outgoing calls cannot be intercepted in AspectJ. This is regarded a lack of symmetry for join point definitions, limitations are presented and discussed. Introduction The goal of attaching a test and monitoring tool to an application is to make calls visible. The tool then can show where a call started and who was called. Details like method and class name and call parameters might be available also. The goal of using aspects and AspectJ [4] is to achieve efficient, flexible and reversible instrumentation at minimal costs. Code instrumentation chooses what components and calls need to be watched and connects an instrumentation library to the application code. At run-time, the tool then can be fed with information about what s going on in the application. The tool can display this information in a variety of views, ranging from lists to detailed interaction diagrams. An instrumentation library generates tool compliant output, defines the steps to follow during instrumentation and what information has to be made available at run-time. The library gets attached to an application by interception techniques. One option is adding the necessary calls to the source code directly. The user mostly doesn t want to monitor all calls, but chooses those specific layers or selected parts of the system that e.g. play a role in a test case or use case. He has concise knowledge about the source code as a prerequisite to making the decision what gets instrumented. It is important to reduce monitoring overhead because the behavior of the system gets changed with every additional library call. This can be looked at as sender side filtering in contrast to applying filter rules to mass data that has already been generated. The definitions of aspects [5], [6] and join points [2] fit well with source code instrumentation. They offer a way for efficient instrumentation. The paper describes some of the requirements for code instrumentation and their relation to aspects and AspectJ, shows two aspect implementations in AspectJ, and discusses results and limitations. The focus is on what can be achieved when applying AspectJ to the core problem. The code shown compiles with AspectJ. 0.4 beta 7. Later versions up to 0.6 beta 2 have been tried also (esp. for the around feature) but they are not used here due to a couple of open issues. Requirements for Code Instrumentation Aspects
2 Code instrumentation requires dumping e.g. method name, parameters and object identity, among other information. The requirements for the aspects are the following:?? The application code gets connected to the instrumentation library.?? Both the start point and the end point of a call has to be monitored.?? Additional information has to be made available, like generation of unique ids for tasks and objects and ids for calls that then let the tool draw a real interaction diagram. These requirements normally tangle the code and don't interfere with application functionality and its software architecture. These observations are helpful because:?? Instrumentation is a crosscutting concern of the application according to the above definition.?? One can conclude that a 'glue' aspect might solve the core part of the problem.?? It is likely that aspects can cover the remaining activities for code instrumentation. Basic library calls for (semi-)automated code instrumentation are:?? Open and close the connection to the TOMDIS java library.?? Register and deregister the network node, process, tasks and objects.?? Dump start and end of an invocation of selected methods with the above library. These activities are captured in two aspects. The first aspect 'TMTEnvAspect' deals with open/close of the library and setting up some environment like the id generator and id propagation. The second one ' TMTTaskAspect ' instruments all involved parts of the application and therefore comprises all steps for monitoring method invocations and the (de)registration of tasks and objects. This is sufficient because only a small set of features of the instrumentation library is required for this evaluation. The Environment Aspect The TMTEnvAspect defines start and stop of instrumentation and provides all common services. It comprises the following activities.?? Define start and stop action and when they occur.?? Provide common data like computer name and process name.?? Provide id generation and mediation. The code for TMTEnvAspect that is presented here contains the parts for in-process monitoring. When adapting the aspect code to an application, the user needs to redefine the bold identifiers at the beginning of the aspect. They describe what class and methods are used as startup and shutdown hooks. aspect TMTEnvAspect { //-- define start and stop action crosscut participants(): SymbolTest; crosscut loadaction(): new(..) & participants(); crosscut closeaction(): void close(..) & participants(); //-- handle outermost events static advice loadaction() { before { EventTracer.deviceRegister(TMTEnvAspect.getLayerName(), TMTEnvAspect.getComputerId(), TMTEnvAspect.getComputerName(), -1, -1); EventTracer.processRegister(TMTEnvAspect.getLayerName(), TMTEnvAspect.getProcId(), TMTEnvAspect.getComputerId(), TMTEnvAspect.getProcessName(), -1, -1); static advice closeaction() { after { EventTracer.deviceUnregister(TMTEnvAspect.getLayerName(), TMTEnvAspect.getComputerId(), -1, -1, true); EventTracer.close();
3 //-- class properties of this aspect //-- Common identifiers static public int getcomputerid() { return computerid; static public int computerid = getnewtaskid(); static public int getprocid() { return procid; static public int procid = getnewtaskid(); static public String getcomputername() { return computername; static public String computername = "Notebook"; static public String getprocessname() { return processname; static public String processname = "Proc"; static public String getlayername() { return layername; static public String layername = "Sym"; //-- Id generator static public synchronized int getnewtaskid() { return newtaskid++; static public int newtaskid = 100; //-- Id propagation static public int getpeerid() { return peerid; static public void setpeerid( int p ) { peerid = p; static public int peerid = 0; The loadaction registers the computer device and the process. Subsequent registration calls require the id of the process to be registered. The closeaction deregisters the device and all dependent processes, tasks and objects recursively and shuts down the instrumentation library. The remaining code contains common read-only information and id handling. The latter consists of an id generation and a simple id propagation, both are kept as simple as possible here. This part of the aspect code doesn t refer to the application in no way, it is part of the aspect architecture only and reflects only requirements for monitoring. The load and close actions get connected to but not adapted to the application code. The AspectJ weaver intercepts the specified methods without exploring the properties of the join points. The aspect implementation fulfills the requirements. The Task Aspect The TMTTaskAspect defines the participants for the test case or use case and the join points and their instrumentation. It comprises the following activities.?? Define the participants and how they get modeled in the tool's event set.?? Enhance the participants with code for proper id handling.?? Register and deregister the participants according to the use case.?? Define the join points and provide weaves that attach them to the TOMDIS library. The code for TMTTaskAspect that is presented here contains the parts for in-process monitoring and reflects its application to a small example from JDK1.2.2 that has received some redesign. The join points dump the minimal information possible, e.g. they don t need to dump call parameters. When adapting the aspect code to an application, the user needs to redefine the crosscuts at the beginning of the aspect. This is sufficient because all weaves get adapted to their join points automatically. aspect TMTTaskAspect { crosscut tasks(): EnterAddressAspect ChoiceAspect; crosscut services(): SymbolTest SymbolCanvas; crosscut rpcclient(): (void configure() & SymbolTest) (void testit() & SymbolTest) (* actionperformed(..) & EnterAddressAspect) (* itemstatechanged(itemevent e) & ChoiceAspect) (* setfont(..) & SymbolCanvas); crosscut rpcserver(): * *(..) & services(); crosscut introaction(): services(); crosscut loadaction(): new(..); //-- Id propapation introduction introaction() { public int getpeerid() { return peerid;
4 public void setpeerid( int p ) { peerid = p; public int peerid = 0; //-- task registration introduction tasks() { public int taskid = TMTEnvAspect.getNewTaskId(); static advice loadaction() & tasks() { after { EventTracer.taskRegister(TMTEnvAspect.getLayerName(), taskid, TMTEnvAspect.getProcId(), thisjoinpoint.classname, -1, -1); //-- service registration introduction services() { public int taskid = TMTEnvAspect.getNewTaskId(); static advice loadaction() & services() { after { EventTracer.serviceProviderRegister(TMTEnvAspect.getLayerName(), taskid, TMTEnvAspect.getProcId(), thisjoinpoint.classname, -1, -1); //-- handle task/provider specific events SERVER static advice rpcserver() { before { thisobject.setpeerid( TMTEnvAspect.getPeerId() ); EventTracer.rpcServerBegin(TMTEnvAspect.getLayerName(), thisobject.taskid, thisobject.getpeerid(), thisjoinpoint.methodname, submitparams, -1, -1); finally { MessageTripleList returnparams = null; EventTracer.rpcServerEnd(TMTEnvAspect.getLayerName(), thisobject.taskid, thisobject.getpeerid(), thisjoinpoint.methodname, submitparams, thisjoinpoint.methodname, returnparams, -1, -1); //-- handle task/provider specific events CLIENT static advice rpcclient() { before { TMTEnvAspect.setPeerId( thisobject.taskid ); EventTracer.rpcClientBegin(TMTEnvAspect.getLayerName(), thisobject.taskid, -1, thisjoinpoint.methodname, submitparams, -1, -1); finally { MessageTripleList returnparams = null; EventTracer.rpcClientEnd(TMTEnvAspect.getLayerName(), thisobject.taskid, -1, thisjoinpoint.methodname, submitparams, thisjoinpoint.methodname, returnparams, -1, -1); The model within tool TOMDIS consists of device, process, task and service where device contains process that in turn contains tasks and services. Actually, it is of no importance if something is a task or a service, both are only views on a thing, but some of the library calls are allowed only for services. The first part of the aspect defines the participants and the join points and sorts all of them into the appropriate category (task, service, rpcclient, rpcserver). The code presents a mixture of specifying join points explicitly and making use of wildcards. The introduction weaves deal with id handling. The task or service requires an id to register itself. At run-time, services store the id of the caller to allow the tool to show nested calls correctly. Advice weaves attach the library to the participant for registration and deregistration. Here, both actions are bound to the life-cycle of the object and the process. in a static and uniform way. This can be achieved by means of keywords in AspectJ that explore the current join point.
5 It is a great advantage that the aspect depends on the join point definitions in the crosscuts and that all advice weaves get adapted to application code automatically. Further more, rpcclients and rpcservers get modeled without referring to each other explicitly. The solution presented here is reusable and efficient. But it is not possible to fulfill all requirements with the current language features in AspectJ. Interception of method invocation traces only the end point of a call. It is not possible to intercept and trace the start point of a call. That means that the interaction diagram and the recorded timestamps for the start point are inexact. Because of this problem, the following workaround is used:?? When a method gets called, a start point of a call is dumped with the tool, assuming that this method might call nested methods that have received instrumentation.?? Then the actual method is called.?? After the method call an end point is dumped, assuming that some nested method was called and has returned to the intercepted method. This workaround fails if the intercepted method calls more than one nested method. When there is no other intermediate object or library in between, other workarounds like pre-instrumented libraries fail also. Timestamps are incorrect in either case. Monitoring an Example Application Before the problems are discussed, two screenshots show what has been achieved so far. The above aspects are a step forward and helpful. The instrumented application created a log file with all information. The following screen dump shows the hierarchy created by the registration calls. Two of the participants are aspects that got instrumented using aspects again. When running the sample application, the following interaction diagram is shown by tool TOMDIS.
6 The boxes on the lines in the sequence chart view are the join points that are defined in TMTTaskAspect. Time stamps have been created by the library calls but they are omitted here. The diagram shows all interaction and registration events that have been relevant. Discussion The second aspect implementation actually points to two issues. The first one is the interception of the start point of a call. The second one is adaptability and generality of weaves. When monitoring calls between objects and components, start and end point need to be traceable to show the exact behavior of a system. Tracing the end point is referred to defining an operation level join point. The start point is only its symmetric counterpart. The end point does not require knowing where the call came from. The start point doesn't require knowing where the call goes to. So this is very different from having introduced plain statement level join points that can cause problems [2]. In contrast, symmetry conveys the same benefits for both points. A method that makes multiple nested calls cannot be instrumented automatically without that symmetric behavior. Adaptability and generality of weaves: In new AspectJ versions, the aspect code from above cannot be used any more because keyword thisobject went away. The action code then has to be bound to the class type that has the join point. That lets the design grow in a way that we end up with almost one aspect per class or at least one advice weave per class. Although instrumentation is a cross cutting concern, its implementation suddenly depends on the number of classes and has to show all names of cross cut classes. Specifying all classes in a package using a wildcard symbol won't work. It is a great advantage if join points and actions on the join points can be specified in a more general way. Everything that is captured by the language doesn't have to be captured by aspect design. But this is not the only reason. The nature of a couple of known cross cutting concerns requires almost identical code for a known or unknown number of join points. The word 'almost' points to two things. If the aspect code has to be reusable, it has to be as general as possible. It reflects the nature of the cross cutting concern, not the one of the join points. At the same time, the code has to be adaptable to some extend because the join points can even be abstract. A sufficient large set of special keywords simplifies aspect designs and reduces the overall effort. Conclusion The two aspects have shown that it is possible to instrument an application using AspectJ efficiently. Together with the tool features, this can be of great help during development and test. Despite of the problems discussed, the approach is quite useful in the current version if the limitations are taken into account, when defining the join points and during the exploration of the results. The aspects employ static weaves and don t dump method parameters, both to support a quick evaluation and maximum performance. The impact on performance when introducing more and more tool features needs further investigation. References [1] Frank Buschmann, Regine Meunier, Hans Rohnert Peter Sommerlad, Michael Stal: A System of Patterns, Wiley and Sons Ltd, 1996 [2] Hardol Ossher, Peri Tarr: Operation-Level Composition: A Case in (Join) Point, Proceedings of ECOOP98 [3] Douglas C. Schmidt, Washington University of St. Louis, home page at
7 [4] AspectJ download page: [5] Gregor Kiczales et al.: Aspect Oriented Programming: A Position paper from the Xerox PARC Aspect Oriented Programming Project, Xerox PARC, 1996 [6] Gregor Kiczales, John Lamping, Anurag Medbeker, Chris Maeda, Cristina Lopes, Jean-Marc Loingtier, John Irving: Aspect Oriented Programming, ECCOP97
Abstract. Introduction
Aspect of Life-Cycle Control in a C++ Framework Lutz Dominick Siemens AG, Corporate Technology, ZT SE 1 D-81730 Munich, Germany Lutz.Dominick@mchp.siemens.de April 1999 Abstract This paper presents some
More informationA Unit Testing Framework for Aspects without Weaving
A Unit Testing Framework for Aspects without Weaving Yudai Yamazaki l01104@sic.shibaura-it.ac.jp Kouhei Sakurai sakurai@komiya.ise.shibaura-it.ac.jp Saeko Matsuura matsuura@se.shibaura-it.ac.jp Hidehiko
More informationUsing AOP to build complex data centric component frameworks
Using AOP to build complex data centric component frameworks Tom Mahieu, Bart Vanhaute, Karel De Vlaminck, Gerda Janssens, Wouter Joosen Katholieke Universiteit Leuven Computer Science Dept. - Distrinet
More informationDynamic Weaving for Building Reconfigurable Software Systems
Dynamic Weaving for Building Reconfigurable Software Systems FAISAL AKKAWI Akkawi@cs.iit.edu Computer Science Dept. Illinois Institute of Technology Chicago, IL 60616 ATEF BADER abader@lucent.com Lucent
More informationMartin P. Robillard and Gail C. Murphy. University of British Columbia. November, 1999
Migrating a Static Analysis Tool to AspectJ TM Martin P. Robillard and Gail C. Murphy Department of Computer Science University of British Columbia 201-2366 Main Mall Vancouver BC Canada V6T 1Z4 fmrobilla,murphyg@cs.ubc.ca
More informationAnalysis of AspectJ Programs
Analysis of AspectJ Programs Maximilian Störzer December 11, 2003 Abstract Program Analysis is increasingly used to enhance program understanding and find flaws in programs. In contrast to testing, it
More informationMining Relationships Between the Participants of Architectural Patterns
Mining Relationships Between the Participants of Architectural Patterns Ahmad Waqas Kamal and Paris Avgeriou Department of Mathematics and Computing Science, University of Groningen, The Netherlands a.w.kamal@rug.nl,
More informationPartial Acquisition Prashant Jain and Michael Kircher
1 Partial Acquisition Prashant Jain and Michael Kircher {Prashant.Jain,Michael.Kircher}@mchp.siemens.de Siemens AG, Corporate Technology Munich, Germany Partial Acquisition 2 Partial Acquisition The Partial
More informationDynamic Weaving for Building Reconfigurable Software Systems
Dynamic Weaving for Building Reconfigurable Software Systems JAGDISH LAKHANI lakhjag@iitedu Computer Science Dept Illinois Institute of Technology Chicago, IL 60616 FAISAL AKKAWI akkawif@iitedu Computer
More informationObject-Oriented Software Development Goal and Scope
Object-Oriented Software Development Goal and Scope Koichiro Ochimizu Japan Advanced Institute of Science and Technologies School of Information Science Scope and Goal Goal enable you to understand basic
More informationImplementing Producers/Consumers Problem Using Aspect-Oriented Framework
Implementing Producers/Consumers Problem Using Aspect-Oriented Framework 1 Computer Science Department School of Science Bangkok University Bangkok, Thailand netipan@iit.edu Paniti Netinant 1, 2 and Tzilla
More informationBugdel: An Aspect-Oriented Debugging System
Bugdel: An Aspect-Oriented Debugging System Yoshiyuki Usui and Shigeru Chiba Dept. of Mathematical and Computing Sciences Tokyo Institute of Technology 2-12-1-W8-50 Ohkayama, Meguro-ku Tokyo 152-8552,
More informationA Brief Introduction to Aspect-Oriented Programming" Historical View Of Languages"
A Brief Introduction to Aspect-Oriented Programming" Historical View Of Languages" Procedural language" Functional language" Object-Oriented language" 1 Acknowledgements" Zhenxiao Yang" Gregor Kiczales"
More informationCourse 6 7 November Adrian Iftene
Course 6 7 November 2016 Adrian Iftene adiftene@info.uaic.ro 1 Recapitulation course 5 BPMN AOP AOP Cross cutting concerns pointcuts advice AspectJ Examples In C#: NKalore 2 BPMN Elements Examples AOP
More informationModel-Driven Design Using Business Patterns
Model-Driven Design Using Business Patterns Bearbeitet von Pavel Hruby 1. Auflage 2006. Buch. xvi, 368 S. Hardcover ISBN 978 3 540 30154 7 Format (B x L): 15,5 x 23,5 cm Gewicht: 1590 g Wirtschaft > Volkswirtschaft
More informationMulti-Dimensional Separation of Concerns and IBM Hyper/J
Multi-Dimensional Separation of Concerns and IBM Hyper/J Technical Research Report Barry R. Pekilis Bell Canada Software Reliability Laboratory Electrical and Computer Engineering University of Waterloo
More informationUniversity of Huddersfield Repository
University of Huddersfield Repository Ghareb, Mazen and Allen, Gary Improving the Design and Implementation of Software Systems uses Aspect Oriented Programming Original Citation Ghareb, Mazen and Allen,
More informationJosh. Java. AspectJ weave. 2 AspectJ. Josh Javassist[1] Javassist Java. AspectJ[3, 4] Java. AspectJ. weave. weave. weave. weave. weaver 1.
Josh Java Aspect Weaver weaver 1 AspectJ Java AspectJ Java weave AspectJ weave Josh weave Javassist weave 1 weaver 1 AspectJ[3, 4] 1 Java AspectJ Java weave Java AspectJ weave Josh Josh Java weave weave
More informationA Brief Introduction to Aspect-Oriented Programming. Historical View Of Languages. Procedural language Functional language Object-Oriented language
A Brief Introduction to Aspect-Oriented Programming Historical View Of Languages Procedural language Functional language Object-Oriented language 1 Acknowledgements Zhenxiao Yang Gregor Kiczales Procedural
More informationAspect-Orientation from Design to Code
Aspect-Orientation from Design to Code Iris Groher Siemens AG, CT SE 2 Otto-Hahn-Ring 6 81739 Munich, Germany groher@informatik.tu-darmstadt.de Thomas Baumgarth Siemens AG, CT SE 2 Otto-Hahn-Ring 6 81739
More informationIntroduction to Design Patterns
Dr. Michael Eichberg Software Technology Group Department of Computer Science Technische Universität Darmstadt Introduction to Software Engineering Introduction to Design Patterns Patterns 2 PATTERNS A
More informationUsing Aspects to Make Adaptive Object-Models Adaptable
Using Aspects to Make Adaptive Object-Models Adaptable Ayla Dantas 1, Joseph Yoder 2, Paulo Borba 1, Ralph Johnson 2 1 Software Productivity Group Informatics Center Federal University of Pernambuco Recife,
More informationAOSA - Betriebssystemkomponenten und der Aspektmoderatoransatz
AOSA - Betriebssystemkomponenten und der Aspektmoderatoransatz Results obtained by researchers in the aspect-oriented programming are promoting the aim to export these ideas to whole software development
More informationChapitre 6 Programmation orientée aspect (AOP)
6 Programmation orientée aspect (AOP) 2I1AC3 : Génie logiciel et Patrons de conception Régis Clouard, ENSICAEN - GREYC «L'homme est le meilleur ordinateur que l'on puisse embarquer dans un engin spatial...
More informationUsing Aspects to Make Adaptive Object-Models Adaptable
Using Aspects to Make Adaptive Object-Models Adaptable Ayla Dantas 1, Joseph Yoder 2, Paulo Borba, and Ralph Johnson 1 Software Productivity Group Informatics Center Federal University of Pernambuco Recife,
More informationPaDA: A Pattern for Distribution Aspects
PaDA: A Pattern for Distribution Aspects Sérgio Soares Universidade Católica de Pernambuco Departamento de Estatística e Informática Centro de Informática Universidade Federal de Pernambuco Paulo Borba
More informationAspect Design Pattern for Non Functional Requirements
Aspect Design Pattern for Non Functional Requirements FAZAL-E-AMIN¹, ANSAR SIDDIQ², HAFIZ FAROOQ AHMAD³ ¹ ²International Islamic University Islamabad, Pakistan ³NUST Institute of Information Technology,
More informationAOP Tutorial. Written By: Muhammad Asif. Department of Computer Science, Virtual University of Pakistan
AOP Tutorial Written By: Muhammad Asif. Department of Computer Science, Virtual University of Pakistan Table of Contents 1.0 INTRODUCTION... 3 2.0 SCOPE AND OBJECTIVE... 4 3.0 MOTIVATION... 5 4.0 HISTORY...
More informationDesigning Aspect-Oriented Crosscutting in UML
Designing Aspect-Oriented Crosscutting in UML Dominik Stein, Stefan Hanenberg, and Rainer Unland Institute for Computer Science University of Essen, Germany {dstein shanenbe unlandr}@cs.uni-essen.de ABSTRACT
More informationUsing Structure and Dependency Tracing Patterns for Aspect Composition
Using Structure and Dependency Tracing Patterns for Aspect Composition Uwe Zdun New Media Lab, Department of Information Systems Vienna University of Economics and BA, Austria zdun@acm.org Abstract Aspects
More informationIntroduction to Design Patterns
Dr. Michael Eichberg Software Engineering Department of Computer Science Technische Universität Darmstadt Software Engineering Introduction to Design Patterns (Design) Patterns A pattern describes... Patterns
More informationextrinsic members RoleB RoleA
ASPECT- ORIENTED PROGRAMMING FOR ROLE MODELS Elizabeth A. Kendall Department of Computer Science, Royal Melbourne Institute of Technology GPO Box 2476V, Melbourne, VIC 3001, AUSTRALIA email: kendall@rmit.edu.au
More informationSeparation of Concerns
Separation of Concerns Erik Ernst Dept. of Computer Science, University of Aarhus, Denmark eernst@daimi.au.dk Abstract. Separation of concerns is a crucial concept in discussions about software engineering
More informationProgramming AspectJ with Eclipse and AJDT, By Example. Chien-Tsun Chen Sep. 21, 2003
Programming AspectJ with Eclipse and AJDT, By Example Chien-Tsun Chen Sep. 21, 2003 ctchen@ctchen.idv.tw References R. Laddad, I want my AOP!, Part 1-Part3, JavaWorld, 2002. R. Laddad, AspectJ in Action,
More informationTowards Better Support for Pattern-Oriented Software Development
Towards Better Support for Pattern-Oriented Software Development Dietrich Travkin Software Engineering Research Group, Heinz Nixdorf Institute & Department of Computer Science, University of Paderborn,
More informationA Novel Approach to Unit Testing: The Aspect-Oriented Way
A Novel Approach to Unit Testing: The Aspect-Oriented Way Guoqing Xu and Zongyuan Yang Software Engineering Lab, Department of Computer Science East China Normal University 3663, North Zhongshan Rd., Shanghai
More informationTransparent Remote Access
Abstract Transparent Remote Access Klaus Marquardt Käthe-Kollwitz-Weg 14, D-23558 Lübeck, Germany Email: marquardt@acm.org In distributed systems, the different processors communicate via network messages.
More informationIntroduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of
Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of Computer Science Technische Universität Darmstadt Dr.
More informationModeling Aspects using Software Stability and UML
Modeling Aspects using Software Stability and UML M.E. Fayad Computer Engineering Department San Jose State University One Washington Square San Jose, CA 9592-080 Ph: 408-924-7364 Fax: 408-924-453 Email:
More informationEuroPLoP 2003 Focus Group: Patterns for Component Composition and Adaptation
EuroPLoP 2003 Focus Group: Patterns for Component Composition and Adaptation Uwe Zdun Department of Information Systems, Vienna University of Economics, Austria zdun@acm.org Markus Voelter voelter - Ingenieurbüro
More informationApplying Aspect Oriented Programming on Security
Original Article Applying Aspect Oriented Programming on Security Mohammad Khalid Pandit* 1, Azra Nazir 1 and Arutselvan M 2 1 Department of computer Science and engineering, National institute of technology
More informationASPECTIX: A QUALITY-AWARE, OBJECT-BASED MIDDLEWARE ARCHITECTURE
ASPECTIX: A QUALITY-AWARE, OBJECT-BASED MIDDLEWARE ARCHITECTURE Franz J. Hauck, Ulrich Becker, Martin Geier, Erich Meier, Uwe Rastofer, Martin Steckermeier Informatik 4, University of Erlangen-Nürnberg,
More informationChapter 32. Aspect-Oriented Software Development (AOSD) Ian Sommerville 2006 Software Engineering. Chapter 32 Slide 1
Chapter 32 Aspect-Oriented Software Development (AOSD) Ian Sommerville 2006 Software Engineering. Chapter 32 Slide 1 Objectives To explain the principle of separation of concerns in software development
More informationAssertion with Aspect
Assertion with Aspect Takashi Ishio, Toshihiro Kamiya, Shinji Kusumoto, Katsuro Inoue Graduate School of Engineering Science, PRESTO, Japan Science and Technology Agency Osaka University 1-3 Machikaneyama-cho,
More informationAspects and Soar: A Behavior Development Model. Jacob Crossman
Aspects and Soar: A Behavior Development Model Jacob Crossman jcrossman@soartech.com Motivation: Why is Soar Useful? Soar Systems are often complex Often require multiple processes Are built of hundreds/thousands
More informationBeyond Aspect-Oriented Programming: Toward Naturalistic Programming
Beyond Aspect-Oriented Programming: Toward Naturalistic Programming Cristina Videira Lopes Institute for Software Research and University of California, Irvine Outline AOP and AspectJ The problem and the
More informationChapter 21 Aspect-Oriented Software Engineering (AOSE)
Chapter 21 Aspect-Oriented Software Engineering (AOSE) Chapter 21 Aspect-Oriented Software Engineering Slide 1 Topics covered Introduction and motivation The separation of concerns Core vs. cross-cutting
More informationCoordinator. Example. Prashant Jain Corporate Technology, Siemens AG Munich, Germany
Coordinator Prashant Jain pjain@gmx.net Corporate Technology, Siemens AG Munich, Germany The Coordinator design pattern describes how to maintain system consistency by coordinating completion of tasks
More informationProgram Instrumentation for Debugging and Monitoring with AspectC++
Program Instrumentation for Debugging and Monitoring with AspectC++ Daniel Mahrenholz, Olaf Spinczyk, and Wolfgang Schröder-Preikschat University of Magdeburg Universitätsplatz 2 D-39106 Magdeburg, Germany
More informationControl-Flow-Graph-Based Aspect Mining
Control-Flow-Graph-Based Aspect Mining Jens Krinke FernUniversität in Hagen, Germany krinke@acm.org Silvia Breu NASA Ames Research Center, USA silvia.breu@gmail.com Abstract Aspect mining tries to identify
More informationA Temporal Logic Language for Context Awareness in Pointcuts
A Temporal Logic Language for Context Awareness in Pointcuts Charlotte Herzeel, Kris Gybels, Pascal Costanza {charlotte.herzeel, kris.gybels, pascal.costanza}@vub.ac.be Programming Technology Lab Vrije
More informationA Distributed Dynamic Aspect Machine for Scientific Software Development
A Distributed Dynamic Aspect Machine for Scientific Software Development Chanwit Kaewkasi Centre for Novel Computing School of Computer Science University of Manchester John R. Gurd Centre for Novel Computing
More informationc Copyright 2004, Vinicius Cardoso Garcia, Eduardo Kessler Piveta, Daniel Lucrédio, Alexandre Alvaro, Eduardo Santana de Almeida, Antonio Francisco
c Copyright 2004, Vinicius Cardoso Garcia, Eduardo Kessler Piveta, Daniel Lucrédio, Alexandre Alvaro, Eduardo Santana de Almeida, Antonio Francisco do Prado, Luiz Carlos Zancanella. Permission is granted
More informationOBJECT-ORIENTED MODELING AND DESIGN. Introduction
OBJECT-ORIENTED MODELING AND DESIGN Introduction Contents: Introduction. Course Relevance Learning Outcomes Overview of the syllabus Introduction to Object Orientation Introduction Object Oriented Approach
More informationContent(2) Contribution of OOT in Software Engineering History of SE Technologies and Contribution of OOT JAIST Koichiro Ochimizu
Content(2) Object-oriented Software Development Methodology Outline of Unified Process and Use-case Driven Approach Elevator Control System: Problem Description and Use-case Model Elevator Control System:
More informationPatterns for Decoupling
Patterns for Decoupling Ingolf H. Krueger Department of Computer Science & Engineering University of California, San Diego La Jolla, CA 92093-0114, USA California Institute for Telecommunications and Information
More informationAspect Oriented Programming
1 Aspect Oriented Programming Programming Languages Seminar Presenter: Barış Aktemur University of Illinois 18 Feb. 2004 Mostly taken from Bedir Tekinerdogan s slides Outline Introduction Problems Terminology
More informationUse Case Level Pointcuts ECOOP 2004 Jonathan Sillito, Christopher Dutchyn, Andrew David Eisenberg and Kris De Volder
Use Case Level Pointcuts ECOOP 2004 Jonathan Sillito, Christopher Dutchyn, Andrew David Eisenberg and Kris De Volder Software Practices Lab THE UNIVERSITY OF BRITISH COLUMBIA My talk is based on some work
More informationConcurrency Control with Java and Relational Databases
Concurrency Control with Java and Relational Databases Sérgio Soares and Paulo Borba Informatics Center Federal University of Pernambuco Recife, PE, Brazil scbs,phmb @cin.ufpe.br Abstract As web based
More informationAn Aspect-to-Class Advising Architecture Based on XML in Aspect Oriented Programming
An Aspect-to-Class Advising Architecture Based on XML in Aspect Oriented Programming T. Hussain, M. M. Awais, S. Shamail, M. A. Adnan Department of Computer Science Lahore University of Management Sciences,
More informationOn the Impact of Aspect-Oriented Programming on Object-Oriented Metrics
On the Impact of Aspect-Oriented Programming on Object-Oriented Metrics Jean-Yves Guyomarc h and Yann-Gaël Guéhéneuc GEODES - Group of Open and Distributed Systems, Experimental Software Engineering Department
More informationAnalyzing effect of Aspect Oriented concepts in design and implementation of design patterns with case study of Observer Pattern
Analyzing effect of Aspect Oriented concepts in design and implementation of design patterns with case study of Observer Pattern Deepali A. Bhanage 1, Sachin D. Babar 2 Sinhgad Institute of Technology,
More informationPatterns in Software Engineering
Patterns in Software Engineering Lecturer: Raman Ramsin Lecture 8 GoV Patterns Architectural Part 2 1 Architectural Patterns: Categories From Mud to Structure Layers, Pipes and Filters, and Blackboard
More informationAspect-Based Workflow Evolution
Aspect-Based Workflow Evolution Boris Bachmendo and Rainer Unland Department of Mathematics and Computer Science University of Essen, D - 45117 Essen {bachmendo, unlandr}@cs.uni-essen.de Abstract. In this
More informationAspect Oriented Programming
Aspect Oriented Programming Jaclyn hang, Hai Huo, Kolton Lehmann, Jeremy Nauta, Henry Rosvick, uong Truong Introduction Objectives ompare Aspect Oriented Programming (AOP) with Object Oriented Programming
More informationUML4COP: UML-based DSML for Context-Aware Systems
UML4COP: UML-based DSML for Context-Aware Systems Naoyasu Ubayashi Kyushu University ubayashi@acm.org Yasutaka Kamei Kyushu University kamei@ait.kyushu-u.ac.jp Abstract Context-awareness plays an important
More informationAnalysing the navigational aspect
A. M. Reina Dpto. Lenguajes y Sistemas Informáticos Universidad de Sevilla. e-mail: reinaqu@lsi.us.es Analysing the navigational aspect J. Torres Dpto. Lenguajes y Sistemas Informáticos Universidad de
More informationAspects and Data Refinement
Aspects and Data Refinement Pavel Avgustinov 1, Eric Bodden 2, Elnar Hajiyev 1, Oege de Moor 1, Neil Ongkingco 1, Damien Sereni 1, Ganesh Sittampalam 1, Julian Tibble 1 1 Programming Tools Group, Oxford
More informationUniAspect: A Language-Independent Aspect-Oriented Programming Framework
UniAspect: A Language-Independent Aspect-Oriented Programming Framework Akira Ohashi Kazunori Sakamoto Tomoyuki Kamiya Reisha Humaira Satoshi Arai Hironori Washizaki Yoshiaki Fukazawa Waseda University
More informationA Flexible Approach for Instance Adaptation during Class Versioning
A Flexible Approach for Instance during Class Versioning Awais Rashid 1, Peter Sawyer 1, Elke Pulvermueller 2 1 Computing Department, Lancaster University, Lancaster LA1 4YR, UK {marash sawyer} @comp.lancs.ac.uk
More informationImproving Software Modularity using AOP
B Vasundhara 1 & KV Chalapati Rao 2 1 Dept. of Computer Science, AMS School of Informatics, Hyderabad, India 2 CVR College of Engineering, Ibrahimpatnam, India E-mail : vasu_venki@yahoo.com 1, chalapatiraokv@gmail.com
More informationSustaining Composability of Aspect-Oriented Design Patterns in Their Symmetric Implementation
Sustaining Composability of Aspect-Oriented Design Patterns in Their Symmetric Implementation Jaroslav Bálik and Valentino Vranić Institute of Informatics and Software Engineering Faculty of Informatics
More informationIdioms for Building Software Frameworks in AspectJ
Idioms for Building Software Frameworks in AspectJ Stefan Hanenberg 1 and Arno Schmidmeier 2 1 Institute for Computer Science University of Essen, 45117 Essen, Germany shanenbe@cs.uni-essen.de 2 AspectSoft,
More informationEvaluation of Separated Concerns in Web-based Delivery of User Interfaces
Evaluation of Separated Concerns in Web-based Delivery of User Interfaces Tomas Cerny 1, Lubos Matl 1, Karel Cemus 1, and Michael J. Donahoo 2 1 Computer Science, FEE, Czech Technical University, Charles
More informationTwo Phase Commit Protocol. Distributed Systems. Remote Procedure Calls (RPC) Network & Distributed Operating Systems. Network OS.
A distributed system is... Distributed Systems "one on which I cannot get any work done because some machine I have never heard of has crashed". Loosely-coupled network connection could be different OSs,
More informationA Model for Software Plans
A Model for Software Plans Robert R. Painter and David Coppit Department of Computer Science The College of William and Mary private static Vector readdata() { BufferedReader stdin = new BufferedReader(
More informationA System of Patterns for Web Navigation
A System of Patterns for Web Navigation Mohammed Abul Khayes Akanda and Daniel M. German Department of Computer Science, University of Victoria, Canada maka@alumni.uvic.ca, dmgerman@uvic.ca Abstract. In
More informationHandling Variability
Handling Variability Version 2.0, December 11, 2009 Markus Völter, Independent/itemis (voelter@acm.org) 2009 Markus Voelter Copyright retain by author(s). Permission granted to Hillside Europe for inclusion
More informationArchitectural Patterns. Architectural Patterns. Layers: Pattern. Architectural Pattern Examples. Layer 3. Component 3.1. Layer 2
Architectural Patterns Architectural Patterns Dr. James A. Bednar jbednar@inf.ed.ac.uk http://homepages.inf.ed.ac.uk/jbednar Dr. David Robertson dr@inf.ed.ac.uk http://www.inf.ed.ac.uk/ssp/members/dave.htm
More informationArchitectural Patterns
Architectural Patterns Dr. James A. Bednar jbednar@inf.ed.ac.uk http://homepages.inf.ed.ac.uk/jbednar Dr. David Robertson dr@inf.ed.ac.uk http://www.inf.ed.ac.uk/ssp/members/dave.htm SAPM Spring 2012:
More informationTransaction Management in EJBs: Better Separation of Concerns With AOP
Transaction Management in EJBs: Better Separation of Concerns With AOP Johan Fabry Vrije Universiteit Brussel, Pleinlaan 2 1050 Brussel, Belgium Johan.Fabry@vub.ac.be March 8, 2004 1 Introduction The long-term
More informationArchitectural Patterns
Architectural Patterns Dr. James A. Bednar jbednar@inf.ed.ac.uk http://homepages.inf.ed.ac.uk/jbednar Dr. David Robertson dr@inf.ed.ac.uk http://www.inf.ed.ac.uk/ssp/members/dave.htm SEOC2 Spring 2005:
More informationCoordination Patterns
Coordination Patterns 1. Coordination Patterns Design Patterns and their relevance for Coordination Oscar Nierstrasz Software Composition Group Institut für Informatik (IAM) Universität Bern oscar@iam.unibe.ch
More informationAspect Oriented Programming for a component-based real life application: A case study
2004 ACM Symposium on Applied Computing Aspect Oriented Programming for a component-based real life application: A case study Odysseas Papapetrou and George A. Papadopoulos Department of Computer Science
More informationSoftware Engineering: Design Aspect-Oriented Programming and Modularity
Software Engineering: Design Aspect-Oriented Programming and Modularity Christian M. Meyer Software Technology Group Darmstadt University of Technology January 29, 2006 1 Aspect-Oriented Programming Aspect-oriented
More informationDesign Patterns. Architectural Patterns. Contents of a Design Pattern. Dr. James A. Bednar. Dr. David Robertson
Design Patterns Architectural Patterns Dr. James A. Bednar jbednar@inf.ed.ac.uk http://homepages.inf.ed.ac.uk/jbednar Dr. David Robertson dr@inf.ed.ac.uk http://www.inf.ed.ac.uk/ssp/members/dave.htm A
More informationAn Introduction to Aspect-Oriented Programming
An Introduction to Aspect-Oriented Programming By Ken Wing Kuen Lee Reading Assignment COMP 610E 2002 Spring Software Development of E-Business Applications The Hong Kong University of Science
More informationDesign Patterns and Aspects Modular Designs with Seamless Run-Time Integration
Design Patterns and Aspects Modular Designs with Seamless Run-Time Integration Robert Hirschfeld *, Ralf Lämmel #, Matthias Wagner * * Future Networking Lab DoCoMo Communications Laboratories Europe Landsberger
More informationAspectC2C: a Symmetric Aspect Extension to the C Language
AspectC2C: a Symmetric Aspect Extension to the C Language Danfeng Zhang, Yao Guo, Xiangqun Chen Key laboratory of High Confidence Software Technologies, Ministry of Education Institute of Software, School
More informationEvolvable Pattern Implementations need Generic Aspects
Evolvable Pattern Implementations need Generic Aspects Günter Kniesel, Tobias Rho Dept. of Computer Science III, University of Bonn Römerstr. 164, D-53117 Bonn, Germany gk,rho@cs.uni-bonn.de Stefan Hanenberg
More informationAspect Repository ORB. Application. Aspect3. Location C
s in Distributed Environments E. Pulvermuller, H. Klaeren, and A. Speck Wilhelm-Schickard-Institut fur Informatik University oftubingen D-72076 Tubingen Abstract. We illustrate how to combine CORBA as
More informationTowards Reusable Heterogeneous Data-Centric Disentangled Parts
Towards Reusable Heterogeneous Data-Centric Disentangled Parts Michael Reinsch and Takuo Watanabe Department of Computer Science, Graduate School of Information Science and Technology, Tokyo Institute
More informationSlide 1. Design Patterns. Prof. Mirco Tribastone, Ph.D
Slide 1 Design Patterns Prof. Mirco Tribastone, Ph.D. 22.11.2011 Introduction Slide 2 Basic Idea The same (well-established) schema can be reused as a solution to similar problems. Muster Abstraktion Anwendung
More informationPatterns for Asynchronous Invocations in Distributed Object Frameworks
Patterns for Asynchronous Invocations in Distributed Object Frameworks Patterns for Asynchronous Invocations in Distributed Object Frameworks Markus Voelter Michael Kircher Siemens AG, Corporate Technology,
More informationWeb Services Annotation and Reasoning
Web Services Annotation and Reasoning, W3C Workshop on Frameworks for Semantics in Web Services Web Services Annotation and Reasoning Peter Graubmann, Evelyn Pfeuffer, Mikhail Roshchin Siemens AG, Corporate
More informationFun with AspectJ. 1 Getting Started. 2 Defining Pointcuts. Cleveland State University Electrical and Computer Engineering Distributed: April 8, 2008
EEC 421/521 Spring 2008 Dr. Nigamanth Sridhar Software Engineering Cleveland State University Electrical and Computer Engineering Distributed: April 8, 2008 Fun with AspectJ AspectJ is a pretty powerful
More informationPattern Transformation for Two-Dimensional Separation of Concerns
Transformation for Two-Dimensional Separation of Concerns Xiaoqing Wu, Barrett R. Bryant and Jeff Gray Department of Computer and Information Sciences The University of Alabama at Birmingham Birmingham,
More informationRaising the Level of Development: Models, Architectures, Programs
IBM Software Group Raising the Level of Development: Models, Architectures, Programs Dr. James Rumbaugh IBM Distinguished Engineer Why Is Software Difficult? Business domain and computer have different
More informationLanguage support for AOP
Language support for AOP AspectJ and beyond Mario Südholt www.emn.fr/sudholt INRIA and École des Mines de Nantes OBASCO project, Nantes, France Language support for AOP ; Mario Südholt; INRIA/EMN; March
More informationContext-oriented Programming for Software Variability at Runtime
Context-oriented Programming for Software Variability at Runtime Robert Hirschfeld Hasso-Plattner-Institut hirschfeld@hpi.uni-potsdam.de svpp 2008, Brussels, Belgium August 8, 2008 ! 1994-1997 Background!
More information