%% This BibTeX bibliography file was created using BibDesk.
%% http://bibdesk.sourceforge.net/


%% Created for Hakim Hannousse at 2009-05-15 18:53:20 +0200 


%% Saved with string encoding Unicode (UTF-8) 



@inproceedings{tracematches,
	Author = {Oege De Moor and Simon Peyton-Jones and Eric Van Wyk},
	Booktitle = {First International Symposium on Generative and Component-based Software Engineering},
	Date-Added = {2009-05-15 18:49:57 +0200},
	Date-Modified = {2009-05-15 18:53:20 +0200},
	Keywords = {Trace-maches},
	Month = {January},
	Pages = {121-133},
	Publisher = {Springer Berlin / Heidelberg},
	Series = {Lecture Notes in Computer Science},
	Title = {Aspect-Oriented Compilers},
	Volume = {1799},
	Year = {2000}}

@inproceedings{aspectj1,
	Address = {London, UK},
	Author = {Gregor Kiczales and Erik Hilsdale and Jim Hugunin and Mik Kersten and Jeffrey Palm and William G. Griswold},
	Booktitle = {ECOOP '01: Proceedings of the 15th European Conference on Object-Oriented Programming},
	Date-Added = {2009-05-15 18:42:35 +0200},
	Date-Modified = {2009-05-15 18:45:15 +0200},
	Pages = {327-353},
	Publisher = {Springer-Verlag},
	Title = {An Overview of AspectJ},
	Year = {2001}}

@inproceedings{SimBot,
	Author = {Paul Hudak and Antony Courtney and Henrik Nilsson and John Peterson},
	Booktitle = {Advanced Functional Programming, 4th International School 2002},
	Date-Added = {2009-05-06 12:15:05 +0200},
	Date-Modified = {2009-05-06 12:19:28 +0200},
	Editor = {Johan Jeuring and Simon Peyton Jones},
	Keywords = {Robots, Arrows, Application Programs},
	Pages = {159-187},
	Publisher = {Springer-Verlag},
	Series = {Lecture Notes in Computer Science},
	Title = {Arrows, Robots, and Functional Reactive Programming },
	Volume = {2638},
	Year = {2003},
	Bdsk-File-1 = { }}

@inproceedings{Fruit,
	Author = {Antony Courtney and Conal Elliott},
	Booktitle = {Proceedings of the 2001 Haskell Workshop},
	Date-Added = {2009-05-05 12:04:35 +0200},
	Date-Modified = {2009-05-05 12:10:39 +0200},
	Keywords = {Arrows, GUI, Application Programs},
	Month = {September},
	Pages = {41-69},
	Publisher = {ACM Sigplan},
	Title = {Genuinely Functional User Interfaces},
	Year = {2001},
	Bdsk-File-1 = { }}

@inproceedings{HPorter,
	Author = {Liwen Huang and Paul Hudak and John Peterson},
	Booktitle = {Practical Aspects of Declarative Languages},
	Date-Added = {2009-05-05 11:57:52 +0200},
	Date-Modified = {2009-05-05 12:02:04 +0200},
	Keywords = {Arrows, Robots, Application Programs},
	Month = {April},
	Pages = {275-289},
	Publisher = {Springer Berlin / Heidelberg},
	Series = {Lecture Notes in Computer Science},
	Title = {HPorter: Using Arrows to Compose Parallel Processes},
	Volume = {4354},
	Year = {2007},
	Bdsk-File-1 = { }}

@inproceedings{depAdvice,
	Abstract = {In this paper, the authors are introduced an extension language to AspectJ by specifying advices dependencies. In this way the runtime overhead is avoided, since only dependent advices are considered. Dependencies are specified using annotations inserted in the same aspect as the relevent advices are defined.

Two kinds of dependencies are proposed:
1. strong dependencies: states that if one of the advices was to execute for which it is known that one of the others never occurs than the execution of that advice is omitted.
2. weak dependencies : states that an advice has to be executed when the others are executed but not the other way around. 

Experiementation has been done to show the impact of the approach in the optimization of the history base. },
	Address = {New York, NY, USA},
	Author = {Eric Bodden and Feng Chen and Grigore Rosu},
	Booktitle = {AOSD '09: Proceedings of the 8th ACM international conference on Aspect-oriented software development},
	Date-Added = {2009-03-24 13:25:13 +0100},
	Date-Modified = {2009-03-24 13:43:20 +0100},
	Keywords = {Dependent Advices, Program history optimization },
	Pages = {3-14},
	Publisher = {ACM},
	Title = {Dependent advice: a general approach to optimizing history-based aspects},
	Year = {2009},
	Bdsk-File-1 = { }}

@proceedings{foal09,
	Abstract = {In this proceedings two papers are interesting:

1. Graph-Based SPECIFICATION AND simulation of Featherweight Java with Around Advice:
       - In this paper, Featherweight java has benn extended with assignement and around advice
       - Runtime semantics is described using GTS based on using three main stacks:
             1. continuation stack: contains expressions to be evaluated
             2. value stack: the result of the evaluated expressions
             3. proceed stack: action postpoined by advices to be called when proceed expression is reached

2. Enhancing base-code protection in aspect-oriented programs:
       - Two AOSD problems are adressed by this paper
                  1. Aspect sensibility to base code changes
                  2. inability of base code to control advising
        - A language called I2 is introduced to specify a so called image interface, which is a languge used by the base program to expose its joinpoints and how thy can be advised, Alias also are associated to joinpoints to reduce coupling between advised and advisers
},
	Address = {New York, NY, USA},
	Date-Added = {2009-03-23 15:49:43 +0100},
	Date-Modified = {2009-03-23 15:56:41 +0100},
	Month = {March},
	Publisher = {ACM},
	Title = {Proceedings of the Eighth Workshop on Foundations of Aspect-Oriented Languag (FOAL'09)},
	Year = {2009},
	Bdsk-File-1 = { }}

@inproceedings{JuryEvalCoCoME,
	Abstract = {In this paper, the authores evaluate the different component models that participate in modelling CoCoME. The authors in the evaluation prefered rather than associating a rank to each model to discuss the strengths and weeknesses of each one and the relation to the CoCoME modelling entended properties. Thus, the moddeling approaches are devided into four main groups :
 
1. Semi-formal modelling: 
    1.1. Kobra : UML-based model 
                    + easy-to-read description
                    + the ability to discuss the design with expert-domains before committing to concrete implementation
                    -  Lack of dedicated tool that ensure that UML is used in a Kobra compliant way
                    - Non-functional properties are not considered
                    - Confusion between Kobra an UML
    1.2. Rish Services : Service-Based model
                   + Architectural support
                   + Tool verification support
                   + Separate logical models from their implementation -> introduce performance optimization at deployment time
                   - hard to compare with other models, since most of them changed the structural view of original CoCoME
2. Formal Modelling Focused on Functional Correctness: Are also devided into three sub-groups
     2.1. Formal State Models : 
             2.1.1. rCOS : Refinement Calculus Based model
                              + Clear and straight-forward object-oriented analysis model
                              + formal support for step-wise refinement
                              + Code generation support through refinement
                              - Unclear relationship to component model
                              - Unclear specification of provable properties by the model
             2.1.2. CoIn: Component interaction automata
                             + Expressive power and flexibility due to the parametrized composition operator
                             + Detailed model
                             + Completeness
                             + Model checking support
                             -  None support of extr-functional properties (?)
    2.2. Formal Algebraic Models :
            2.2.1. Focus/AutoFocus :
                            + Ability to model reactive systems
                            - unable to model system instantiation, it only supports fixed structures
           2.2.2. Java/A : 
                           + Ability to derive properties of composite componets throught their inner components          
                           + Avoid architectural erosion
                           -  The relation of observational equivalance is so strong property
                           * Quantitative aspects can be integrated into Java/A
    2.3. Formal Object Models :
            2.3.1. Cowch : 
                          + Clear semantics fundation on top of object-oriented programming languages
                          + Model the complete functional and structural properties of CoCoME
                          + Fill the gap between high-level architecture and desciption techniques
                          - Behavioral part is not modeled, it is only refered to Java Code
                          - Strongly related to code, it is not at the higher level of abstraction
                          - Does not support verification and analysis
         2.3.2. DisCComp :
                         + provides a sound semantic model for concurently executed components
                         - Unclear approach for specifying  CoCoME
                         - None support for non-functional properties
3. Formal Models Focusing on behavior and Quality Properties
     3.1. Palladio :
                + Provides different architectural design alternatives supporting their design decisions with quntitative performance prediction
                + Able to model complex system interactions such as Use case 8 of CoCoME
    3.2. Fractal :
                + Support different concepts of CBSE from architectural design to deployment -> Better way to model appliaction like CoCoME
                - Does not support asynchronous communication
                - Does not support extra-functional perperties
    3.3. SOFA :
               +  As Fractal with support of asynchrounous communication
               + Compared to Fractal the specification code is less than the specification of Fractal

4. Models Tailored for a Specific Application Domain
     4.1. GCM/ProActive :
               + Seamless distrubution due to the support of virtual nodes

As final conclusion, the authors show that none of the presented models is able to model the whole system of CoCoME and that is due to the incompleteness of the existing models i.e. they are still under developement.  },
	Author = {Manfred Broy and Johannes Siedersleben and Clemens Szyperski},
	Booktitle = {The Common Component Modeling Example},
	Date-Added = {2009-03-08 12:23:23 +0100},
	Date-Modified = {2009-03-09 16:04:32 +0100},
	Keywords = {CoCoME, Taxonomy},
	Month = {August},
	Pages = {449-458},
	Publisher = {Springer Berlin / Heidelberg},
	Series = {Lecture Notes in Computer Science},
	Title = {CoCoME Jury Evaluation and Conclusion },
	Volume = {5153},
	Year = {2008},
	Bdsk-File-1 = { }}

@inproceedings{CowchCoCoME,
	Abstract = {In the first part of this paper, the authors presents a component model based on Boxes. A component in Cowch consists of an ordinary Java object with a set of so-called helpper objects which are objects used only by the underlying object to ensure its functionality. The inner objet with all its object helpers are encapsulated on a structure called box. This box has a set of ports which are considerd as the only way to communicate with the inner object. Boxes support ingoing and outgoing ports, Also, they support outgoing and ingiong methods which de not bemong to any specific port. outgoing and ingoing ports are used to avoid the creation of artificial interfaces when only one method have to be considered in the communication. 

Boxes also support synchronous and asynchronous messages. While synchrounous messages are ordinary Java methods, asynchrouns methods are defined using Chords. A Chord is a method-like artifact but it has a set of methods as arguments. The body of the Chord is executed only when all its method arguments are executed. 

Connection ports in Cowch consists of creating channels. Both boxes and channels in Cowch maybe either durable or optional. Boxes also maybe multiple ar single.

The Cowch approach includes three layers : 
1. Architectural Modeling layer : is used to describe gaphically the structure of sofware systems, a language called MCawch is introduced for this purpose.
2. Executable Modelling Layer: is used to describe textually the structure and the behavior of software systems. A special language called JCowch is defined for this purpose. The behavior of systems is described as Java syntax. Note that the semantics of MCowch is defined by its consistency to JCowch language.
3. Implementation Layer: is used as an implementation of the software system which is a refinement of a JCowch program to Java program, where the consistency is preserved.      

Active arnd reactive components are also supported by MCowch.

The second part of the paper, the authors are described the corresponging MCowch Layer of the CoCoME. All ports, interfaces, boxes are specified. Event Channels are specified as Chords for supporting asynchronous communication. The detail of the model has been taken from the Jave implementation reference of CoCoME.

The Cowch approach is at the beginning stage, so behavioral specification is not yet allowed by the model. Thus formal analysis of functional behavior is not yet considered. However, the authors have claimed that some errors are encountred when analysing the reference implementaion of CoCoME. Some of them are that the CardReaderController did not recieve any message and it is not disabled when expressCheckout is enable.

No concrete tools are available for the approach, but it is claimed that are under consideration. 

 },
	Author = {Jan Sch\"{a}fer and Markus Reitz and Jean-Marie Gaillourdet and Arnd Poetzsch-Heffter},
	Booktitle = {The Common Component Modeling Example: Comparing Software Component Models},
	Date-Added = {2009-03-05 12:58:32 +0100},
	Date-Modified = {2009-03-05 14:11:22 +0100},
	Keywords = {Cowch, Boxes, Architectural programming, CoCoME, Component},
	Month = {August},
	Pages = {238-266},
	Publisher = {Springer Berlin / Heidelberg},
	Series = {Lecture Notes in Computer Science},
	Title = {Linking Programs to Architectures: An Object-Oriented Hierarchical Software Model Based on Boxes},
	Volume = {5153},
	Year = {2008},
	Bdsk-File-1 = { }}

@inproceedings{PalladioCoCoME,
	Abstract = {In this paper the authores uses The PCM approach to predict some of the extra-functional properties during the design of CoCoME. Only use case 8 is modularized using PCM. Thus, only two main components are defined : Inventory data and inventory store. CashDesk and Database are considered as external services, so they are not modularized.

The PCM modularization of CoCoME is transformed into Capra expression to analyse the specified extra-functional properties. Also, a simulation approach is modeled to a queuing Network to simulate usage of ressources. The ressources considered in that case are: CPU and Communication. The extra-functional properties analused are time execution of bookSale() method.

The analysis results shows that the provided model for CoCoME is not able to support 200 store servers as expected. The responce time will be unappropriate.

The PCM approavh has some limitation w.r.t CoCoME application:
1. Component staes are not supported by the approach.
2. Dynamic reconfiguration also is not supported
3. It supports only one-to-one connection
4. Composite components are just boxes including primitive ones
5. Doesn't support embeded systems
6. Only sustems maybe allocated to ressources},
	Author = {Klaus Krogmann and Ralf Reussner},
	Booktitle = {The Common Component Modeling Example},
	Date-Added = {2009-03-03 15:55:57 +0100},
	Date-Modified = {2009-03-04 15:58:57 +0100},
	Keywords = {CoCoME, Palladio, Component},
	Month = {August},
	Pages = {297-326},
	Publisher = {Springer Berlin / Heidelberg},
	Series = {Lecture Notes in Computer Science},
	Title = {Palladio -- Prediction of Performance Properties},
	Volume = {5153},
	Year = {2008},
	Bdsk-File-1 = { }}

@article{Palladio,
	Abstract = {In this paper, the Palladio Component Model PCM, is introduced. PCM is UML-like driven model used to predict perfermance at the earlier stage of design of software systems.

The PCM approach is a multi-role modelling approach, in the sence that many actors may interact to model a software system, where each actor uses a specific model to achieve the design step:
1. Developper(s): specify and implement primitive components and put them in a repository. Some QoS specification informations can be associated to services. Developper uses the repository model. The repository model may contains a set of first class entities such as components, interfaces, connections. Interfaces are considered as first class enties because the architects may define new interfaces to be implemented by developpers in the case of missed behavior for a system.

2. Architects : costruct software architect from primitive components, associating caracterization points to be used for software implementation. Thus, architects uses the repository model and the system model. The system model is used to construct the final artifact of software systems, it s a composite-like component but it just shows its provided and required interfaces and doesn't show its inner components.

3. Deployers : allocate software arifacts to physical nodes and complete the preformance anaylsis information by giving a value to the parametrized variables provided by architects and developpers. Thus they use three models: Allocation, Ressource types and Ressource Environment.

5. Domain experts : Provides a concrete values for the parameters provided bu other actors and uses Usage Model to provide a set of scenarios describing different usage cases of the system. 

Note that the PCM approach is not a waterfall approach, because at any time the actors may interact to update their own models.

A simulation approaches maybe used to determine the prediction values of the execution process of software systems. Tool supports are provided by the model and  eclipse plug-ins, such us: PCMBench.    },
	Author = {Steffen Beckera and Heiko Koziolekb and Ralf Reussner},
	Date-Added = {2009-03-03 15:36:28 +0100},
	Date-Modified = {2009-03-04 14:34:58 +0100},
	Journal = {Journal of Systems and Software},
	Keywords = {component-Based Software Development, Software Architecture, Performance prediction},
	Number = {1},
	Pages = {3-22},
	Title = {The Palladio component model for model-driven performance prediction},
	Volume = {82},
	Year = {2009},
	Bdsk-File-1 = { },
	Bdsk-File-2 = { }}

@inproceedings{GCM,
	Abstract = {In this paper, the authors introduces the Grid Component Model (GCM) which extensions Fractal Component model by introducing Grid Concepts.

A Component in GCM may contains one or more active objects. 

Two specific interfaces are added : broadcasting and gathercasting interfaces. Besides primitive and Composite components, the concept of parallel component is introduced to Fractal. A parallel component is a composite component which has at least on broadcasting interface which has the same signature as the different primitive components they belong to.

The ADL description of the architecture jas been also extended to support parallel component definition, the binding between the primitive components wuth their parallel component is made automatically.

The deplyment descriptor is also extended to upport virtual nodes and their mapping to to real JVMs. Note that one VN can be mapped onto a set of JVMs.},
	Author = {Fran{\c c}oise Baude and Denis Caromel and Matthieu Morel},
	Booktitle = {On The Move to Meaningful Internet Systems 2003: CoopIS, DOA, and ODBASE},
	Date-Added = {2009-03-02 15:18:06 +0100},
	Date-Modified = {2009-03-02 15:22:38 +0100},
	Keywords = {Active Objects, Component, hierachical component models, Grid, Deployment},
	Month = {October},
	Pages = {1226-1242},
	Publisher = {Springer Berlin / Heidelberg},
	Series = {Lecture Notes in Computer Science},
	Title = {From Distributed Objects to Hierarchical Grid Components},
	Volume = {2888},
	Year = {2003},
	Bdsk-File-1 = { }}

@article{ProActive,
	Abstract = {In this paper, the author introduced the concept of Active objects into Java programming Languge. An active object extended standard Java object by a queue saving incomming calls to the object. A strategy of managing that queue is FIFO, but the user can personalize the definition of its strategy. Any call to the active object should be make using a proxy. Active objects are associted into virtual nodes which are abstractions of the real infrastructure of the system. The model is developped as an extended libraray to Java.},
	Author = {Denis Caromel and Wilfried Klauser and Julian Vayssi{\`e}re},
	Date-Added = {2009-03-02 13:34:42 +0100},
	Date-Modified = {2009-03-02 15:05:49 +0100},
	Journal = {Concurrency Practice and Experience},
	Keywords = {Grid, Active Objects, Deployment},
	Month = {December},
	Number = {11-13},
	Pages = {1043-1061},
	Title = {Towards Seamless Computing and Metacomputing in Java},
	Volume = {10},
	Year = {1998},
	Bdsk-File-1 = { }}

@inproceedings{PNets,
	Abstract = {In this paper,a formal model for pNets is described and applied to model distributed Java Objects following ProActive implementation.

A pNet in fact is a pLTSs connected with links, pLTSs are LTSs associated with arguments. As UPPAAL, transitions are described as a guard, action and update statements. States are associated with the updated variables.

The provided model generate a pNet from a proAvtive source code by:
1. data abstraction: transform user class types to sim{\`u}ple types; semi-automatic step
2. Topology and communication Extraction: from the abstracted ProActive code, the architecture of the pNet is extracted by creating a box for each active object class which has a set of creation points corresponding to the public methods defined in each class and links are extracted from the control flow of the code.
3. Extended Method Call Graph: An pLTS is created for each active object class describing the contol flow of the code.
 },
	Author = {Tom{\'a}s Barros and Rab{\'e}a Boulifa and Eric Madelaine},
	Booktitle = {Formal Techniques for Networked and Distributed Systems (FORTE 2004)},
	Date-Added = {2009-03-02 13:09:07 +0100},
	Date-Modified = {2009-03-02 13:17:20 +0100},
	Keywords = {pNets, Distributed Applications, Active Objects},
	Month = {September},
	Pages = {43-60},
	Publisher = {Springer Berlin / Heidelberg},
	Series = {Lecture Notes in Computer Science},
	Title = {Parameterized Models for Distributed Java Objects},
	Volume = {3235},
	Year = {2004},
	Bdsk-File-1 = { }}

@inproceedings{GCMCoCoME,
	Abstract = {In this paper, the authors introduced the Grid concepts to Fractal Component Model. The main extensions are:
1. support of asynchronous method calls
2. collective interfaces : multicast and gathercast interfaces
3 The concept of Virtual Nodes VNs and their specification with ADL

In ProActive implementation of GCM, each component is associted to a an active object (i.e. thread).

The pNets formal model is presented to describe the behavior of components, however, pNets doesn't support complex data-types for that reason, a type abstraction phase should be performed before using pNets.

A Java Distributed Component Specification Language JDC is presented to describe the architecture of compnent systems (Struture and behavior: policy)

CCTool is discussed with its limitations to support only synchronous communications.

In the context of CoCoME, the CashDesk and CashBoxController are only designed using JDC. While the automatic generation is not yet implemented with it, Java code skeletons of components and ADL description are manually generated.

The analysis phase of CoCoME has been performed using manual build of pNets describing the behavior of components and formulas to be checked are described as automaton and passed to the Evaluator model checker (from CADP toolset) for verification. 

Some properties have been checked:
1. deadlock freedness : not satisfied due to the exception spcification model used by the authors and the consideration of su-ynchronous communication for the EventBus component
2. New sale cannot be started while another is not yet finished in the same cashDesk : satisfied
3. Booking an empty sale : not satisfied
4. Successful sale with insufficient money : not satisfied
5. Safty of the express mode: not satisfied     },
	Author = {Antonio Cansado and Denis Caromel and Ludovic Henrio and Eric Madelaine and Marcela Rivera and Emil Salageanu},
	Booktitle = {The Common Component Modeling Example: Comparing Software Component Models},
	Date-Added = {2009-03-01 15:51:53 +0100},
	Date-Modified = {2009-03-01 16:00:57 +0100},
	Keywords = {CoCoME, Components, Distributed Systems, Grid, ProActive},
	Pages = {418-448},
	Publisher = {Springer Berlin / Heidelberg},
	Series = {Lecture Notes in Computer Science},
	Title = {A Specification Language for Distributed Components Implemented in GCM/ProActive},
	Volume = {5153},
	Year = {2008},
	Bdsk-File-1 = { }}

@inproceedings{CoInCoCoME,
	Abstract = {In this paper the CoIn Model is introduced with the three main component composition operators:
1. cub-like composition : cartisian product of component states
2. star-like composition: from the initial state, the component may start executing any of its methods but cannot start a new one before the previous one is fifnshed
3. handshake-like composition: Anytime a component inside the composite is ready to perform an action that has its counterpart at one of the other components, it waits for this component to synchronize on the action.

Also, an extended version of LTL is presented, the extended version has two new operators:
1. psi(l) : means l is enabled and is true in all states of the system such that the interaction represented by l can possibly happen
2. P(l) : L IS PROCESSING AND IS TRUE WHENEVER THE INTERACTION REPRESENTED BY L IS ACTUALLY Happening

The CoCoME is modeled following the next steps:
1. each method of the in a component is modeled as an independent CI automata
2. the primitive component is modeled by composition its corresponding Methods automata following the composition operators that compliant with the implementation requirement
3. a composite component is modeled as a composition of the CI automaton of its corresponding primitive components

In the model, they accept the structural view of CoCoME already presented in the original paper with the integration of the evntChannel component inside the cashDeskLine component.

The properties to be verisifed are specified using the proposed extended version of LTL formulae and checked using the DiVinE model checker. The authors claimed that no deadlock is occured during the verification process of the CoCoME implementation.
},
	Author = {Barbora Zimmerova and Pavl\'{\i}na Va\v{r}ekov\'{a} and Nikola Bene\v{s} and Ivana \v{C}ern\'{a} and Lubo\v{s} Brim and  Ji\v{r}\'{\i} Sochor},
	Booktitle = {The Common Component Modeling Example: Comparing Software Component Models},
	Date-Added = {2009-02-19 13:32:11 +0100},
	Date-Modified = {2009-02-19 13:39:22 +0100},
	Keywords = {CoIn, Components, Verification, Component Interaction},
	Pages = {146-176},
	Publisher = {Springer Berlin / Heidelberg},
	Series = {Lecture Notes in Computer Science},
	Title = {Component-Interaction Automata Approach (CoIn)},
	Volume = {5153},
	Year = {2008},
	Bdsk-File-1 = { }}

@article{CoIn,
	Abstract = {In this paper, authors introduced a framework bason on ADL descripyion language to describe the architecture of component software and a Component intercation automaton to describe their behavior interactions. This way a software enginners should first used ADl language to describe the software architect with their behavior, a tool support is used to transform the component behavior description into general forml model (i.e. Automatan), afterthat, the hierarchical component composition is build with respect to ADL description structure and the way of communication among components. Finaly a model checker is used to verify properties of of the result model.

In the first part of the paper, the authors discusses the ADL description lanuages that are used to specify software components with their pros and cons (i.e. comprehensible and very suitable for specification of hierarchichical component architecture with their interactions but thy suffer from supporting only a fis-xed set of properties verification). Also they discussed some specification and verification process based on general formal languages that are good in verification but they don't take into account the architecture aspect of components.

I/O Automata
-----------------
1. Input enabled in all states => Doesn't capture the case where a component A send output action a to B which is not ready to handle it
2. Input and output actions are disjoint => Doesn't consider action delegation between components
3. Automaton wthin the same output actions cannot be composed => Doesn't consider the case where some components use the same service of another components
4. Doesn't specify which inputs and outputs should be bound and which should stay unbound

Interface Automata
--------------------------
It is better than the I/O automata in the sence that is not enabled in all states. But it has some shutcomings:
1. It allows the composition of two compenets only => The model doen't allow multiple binding
2. input, output and internal actions are disjoints
3. Explicitly ndicate error states.

Team Automata:
----------------------
It is like Interface automata but alows the composition of more than tonly two components. But It also has some drawbacks:
1. A set of component automata is composable iff the internal actions of all the components are disjoints
2. The composition hides every input action which is an output action of some other automaton in the composition => The input action cannot be used later on
3. When composing we loose some information about the behavior of the system

Component-Interaction Automata differs from other models by the providing the following properties:
1.  The inouts are not enabled in all states
2.  Input, Output and internal actions are not distincts
3. Input and outputs actions are associated with the name of the component recieving or sending the actions
4. In the composition only two components are synchronized and their comunicatin information is preserved but the authors claimed that the model is power enough to support mult-way synchronization
5. The architecture and the communication way described by ADL specification is preserved.
6. Primitiveness of composites is formaly defined.
7. LTL is used to specify properties for verification process and DiVinE model checker is used to verify such formulae.},
	Address = {New York, NY, USA},
	Author = {Lubo\v{s} Brim and Ivana \v{C}ern\'{a} and Pavl\'{\i}na Va\v{r}ekov\'{a} and Barbora Zimmerova},
	Date-Added = {2009-02-18 11:24:53 +0100},
	Date-Modified = {2009-02-18 14:26:03 +0100},
	Journal = {ACM SIGSOFT Software Engineering Notes},
	Keywords = {ADL, I/O Automata, Component Interaction, Verification},
	Month = {March},
	Number = {2},
	Pages = {1-8},
	Title = {Component-interaction automata as a verification-oriented component-based system specification},
	Volume = {31},
	Year = {2006},
	Bdsk-File-1 = { }}

@inproceedings{DisCCompCoCoME,
	Abstract = {In this paper, the authors are tried o modularize CoCoME with DisCComp component model. However, only the ChangePrice use case is specified and only consistency in interface mapping is analysed.

The prcess model in using DISccomp consists of two steps:
1. Describe primitive components using :
     1.a. UML component diagram and class diagrams for static behavior.
     1.b. OCL to specify required interfaces as pre/post conditions
     1.c. DisCComp syntax ans semantics to describe the behavior of provided interfaces
2. wirring components to constract composite ones is checked by program analysis techniques to show whether the provided interfaces fullfils the contracts specified by the required interfaces. Note that a provided interface of a composite my delegate the call to the corresponding inner component interface or can use inner component interfaces to fullfils their functionality},
	Author = {Andr\'{e} Appel and Sebastian Herold and Holger Klus and Andreas Rausch},
	Booktitle = {The Common Component Modeling Example: Comparing Software Component Models},
	Date-Added = {2009-02-16 14:10:22 +0100},
	Date-Modified = {2009-02-17 13:33:47 +0100},
	Keywords = {CoCoME, DisCComp, Distributed Systems},
	Month = {August},
	Pages = {267-296},
	Publisher = {Springer Berlin / Heidelberg},
	Series = {Lecture Notes in Computer Science},
	Title = {Modelling the CoCoME with DisCComp},
	Volume = {5153},
	Year = {2008},
	Bdsk-File-1 = { }}

@article{DiSCComp,
	Abstract = {The autors in this paper, presented a formal model based on set theory and relations based-model to describe the operational semantics of DiCComp. The presented fromal models takes into account the following points:
1. global state sharing
2. asynchrouns message communication
3. concurrent synchronous method call and returns
4. dynamic change of the system structure 

The proposed model has two view : description and instance views. The description view is based on And Extended version of the UML sequence and component diagrams to describe threads and asynchronous message communication. 

The instance view describes the semantics over the the description view using set theory and relations. The Instance view is described as a relation of system and all its parts: components, interfaces, attributes, connections messages, threads and values.

The structural changing is described by a set of functions:
1. Alive: to show if a specifc part of the system is active or not
2. Assignement : to associate an interface to a component
3. Allocation: to associate an attribute to an interface
4. CONNECTS : To associae a connection between interfaces

The global state sharing is modeled as a VALUATION function to associte a value to each attribute

The asynchronous communication is modeled as a function over interfaces to show the sequence of messages arrived and sent by a specfic interface

The concurrent method calls is modeled as a stack assiciated to each thread. Such that each method call implies creating a new thared with an empty stack that can be updated with other internal method calls or asynchronous messages

The whole system is described as SNAPSHOT that is a relation of the all previosly described relations.

The system behavior is described as a relation form observation points described as natural numbers to a tuple that consists of all the priviously described relations at the same observable point.

The thread behavior is described as a trnsition from a SNAPSHOT to another by execution the method call.

A runtime system is described to check which thread to be executed and manges them by excuting the corresponding changes. Also it is able to describe the case of inconsistency at the the execution time.

At the end the authors described a frmawork called DesignIt that implements DisCComp as three steps. 
1. The UML descrition is made
2. and XML generator is used to generate the XML like description of the UML ones
3. XSLT TOOL IS USED TO GENERATE the corresponding Jave code.
Within this tool the application can be started and the runtime environment which is implemented as an extension to CORBAis able to detect the inconsistency cases and tell tem the used to make a change to the UML description and the process will be executed again until the system will be consistent.   },
	Author = {Andreas Rausch},
	Date-Added = {2009-02-10 11:10:38 +0100},
	Date-Modified = {2009-02-16 13:42:06 +0100},
	Journal = {Electronic Notes in Theoretical Computer Science},
	Keywords = {Software Architecture, Distributed Systems, component-Based Software Development, concurrency},
	Number = {2},
	Pages = {5-23},
	Title = {DisCComp - A Formal Model for Distributed Concurrent Components},
	Volume = {176},
	Year = {2007},
	Bdsk-File-1 = { }}

@inproceedings{Tax3,
	Abstract = {In this paper, the authors presented a taxonomy of the CBSE methods based on the following criteria:

1. Formality (Informal, sem-formal and formal) : specifies the mathemathical fundation of the methods
2. Principles (MODULARITY? robustness, Flexibility, Quality, Interoperability): specifies the supported quality concepts by the methods
3. Supported Properties : functional and non-functional aspects of the system, and product oer process at the development phase
4. Application domains
5. Abstraction level (High, Medium and Low): specifies at which level of the software life-cycle the method could be used
6 Strategy (Top-down, Hybrid and bottom-up): specifies how component assemblies are constructed.

A spider-web shart is proposed to apply the taxonomy on the CBSE methods, where each access in the chart represents one of the criteria and each axis is devided into values describing the supported properties of each method.

According to the authors this taxonomy can be used to for comprehensive overview of the existing methods and also to identify while-spots and areas of future work. },
	Author = {Christian Bunse and Felix C. Freiling and Nicole Levy},
	Booktitle = {Architecting Systems with Trustworthy Components},
	Date-Added = {2009-02-09 17:29:36 +0100},
	Date-Modified = {2009-02-09 17:36:21 +0100},
	Editor = {Ralf H. Reussner and Judith A. Stafford and Clemens A. Szyperski},
	Keywords = {Taxonomy, Components},
	Month = {July},
	Pages = {103-119},
	Publisher = {Springer Berlin / Heidelberg},
	Series = {Lecture Notes in Computer Science},
	Title = {A Taxonomy on Component-Based Software Engineering Methods},
	Volume = {3938},
	Year = {2006},
	Bdsk-File-1 = { }}

@article{FAC2,
	Author = {Nicolas Pessemier and Lionel Seinturier and Laurence Duchien and Thierry Coupaye},
	Date-Added = {2009-02-09 13:34:59 +0100},
	Date-Modified = {2009-02-09 13:45:11 +0100},
	Journal = {Int. J. Computer Applications in Technology},
	Keywords = {AOSD, Components, CBSE, Aspect Components, Aspect Domains, Aspect Binding},
	Number = {1/2},
	Pages = {94-105},
	Title = {A component-based and aspect-oriented model for software evolution},
	Volume = {31},
	Year = {2008},
	Bdsk-File-1 = { }}

@inproceedings{FAC1,
	Abstract = {In this paper, The authors introduces the FAC (Fractal Aspect Components) framework. This framework describes a symetic approach to aspect and compoenets in the sence that aspects are described as ordinary components. Three main concepts are introduced to fractal:

1. Aspect Components (ACs) : Encapsulated the code of around advices to be woven to ordinary components
2. Aspect binding: are specific relations between ACs and Components 
3. Aspect Domains: Overview of the application of ACs to Components.

A metamodel of FAC is presented extending the metamodel of Fractal by the the three main concepts introduced by FAC. 

As FAC supports AOP it hs to implement the AOP artifacts:
1. Join Points: FAC supports only incoming and outgoing calls. That is due with the respect to the Component Encapsulation
2. Pointcuts: A point cut expression in FAC is of the form: [SERVER/CLIENT] C; I; M:Type 
3. Any AC should implement the AspectComponent Interface that declares the invoke method. The invoke method has a reified intercepted method as parameter. The AC in turn should implement the invoke method to describe the behavior of the aspect. The original method could be called again using the proceed method. if more than one aspect should be applied the proceed refer to the next aspect until the method is invoked.
3. Weaving Mechanism: The weaving is supported by FAC by associated a controller interface that should be implemented by each component will be impacted by an aspect. This interface contains methods to bind and unbind aspects also to weave and unweave ACs to that component. An AC can be applied to a Fractal component in recursive way in the sence that the aspect may be applied to a component and to to all its subcomponents. At the weaving time a new domain is created.
},
	Author = {Nicolas Pessemier and Lionel Seinturier and Thierry Coupaye and Laurence Duchien},
	Booktitle = {Software Composition : 5th International Symposium, SC 2006},
	Date-Added = {2009-02-09 11:05:22 +0100},
	Date-Modified = {2009-02-09 12:54:50 +0100},
	Editor = {Welf L{\"o}we and Mario S{\"u}dholt},
	Keywords = {Components, Aspects, Aspect Components, Aspect Domains, Aspect Binding},
	Month = {March},
	Pages = {259-274},
	Publisher = {Springer Berlin / Heidelberg},
	Series = {Lecture Notes in Computer Science},
	Title = {A Model for Developing Component-Based and Aspect-Oriented Systems},
	Volume = {4089},
	Year = {2006},
	Bdsk-File-1 = { }}

@inproceedings{rCOSCoCoME,
	Author = {Zhenbang Chen and Abdel Hakim Hannousse and Dang Van Hung and Istvan Knoll and Xiaoshan Li and Zhiming Liu and Yang Liu and Qu Nan and Joseph C. Okika and Anders P. Ravn and Volker Stolz and Lu Yang and Naijun Zhan},
	Booktitle = {The Common Component Modeling Example},
	Date-Added = {2009-02-06 13:36:13 +0100},
	Date-Modified = {2009-02-06 13:42:30 +0100},
	Keywords = {Requirements Modelling, design, Refinement, Transformation},
	Month = {August},
	Pages = {116-145},
	Publisher = {Springer Berlin / Heidelberg},
	Series = {Lecture Notes in Computer Science},
	Title = {Modelling with Relational Calculus of Object and Component Systems - rCOS},
	Volume = {5153},
	Year = {2008},
	Bdsk-File-1 = { }}

@inproceedings{rCOSCM2,
	Author = {Xin Chen and Jifeng He and Zhiming Liu and Naijun Zhan},
	Booktitle = {International Symposium on Fundamentals of Software Engineering (FSEN)},
	Date-Added = {2009-02-06 13:17:39 +0100},
	Date-Modified = {2009-02-06 13:35:59 +0100},
	Keywords = {components, Contracts, Protocols, Composition, Glue Codes, Application Programs, Refinement},
	Month = {October},
	Pages = {191-206},
	Publisher = {Springer Berlin / Heidelberg},
	Series = {Lecture Notes in Computer Science},
	Title = {A Model of Component-Based Programming},
	Volume = {4767},
	Year = {2007},
	Bdsk-File-1 = { }}

@inproceedings{rCOSCM1,
	Author = {He Jifeng and Xiaoshan Li and Zhiming Liu},
	Booktitle = {Theoretical Aspects of Computing -- ICTAC 2005},
	Date-Added = {2009-02-06 13:08:58 +0100},
	Date-Modified = {2009-02-06 13:16:19 +0100},
	Keywords = {Components, Interfaces, Contracts, Protocols, Functionality, Consistency, Composition, Refinement, Simulation},
	Month = {October},
	Pages = {70-95},
	Publisher = {Springer Berlin / Heidelberg},
	Series = {Lecture Notes in Computer Science},
	Title = {Component-Based Software Engineering: The Need to Link Methods and Their Theories},
	Volume = {3722},
	Year = {2005},
	Bdsk-File-1 = { }}

@article{rCOSTheory,
	Author = {He Jifeng and Xiaoshan Li and Zhiming Liu},
	Date-Added = {2009-02-06 12:59:30 +0100},
	Date-Modified = {2009-02-06 13:05:04 +0100},
	Journal = {Theoretical Computer Science},
	Keywords = {Object Orientation, Refinement, Semantics, UTP},
	Month = {July},
	Number = {1-2},
	Pages = {109-142},
	Title = {rCOS: A refinement calculus of object systems},
	Volume = {365},
	Year = {2006},
	Bdsk-File-1 = { }}

@inproceedings{unifMod1,
	Abstract = {The author in this paper introduced his framework that supports CBP, AOP and ADL. He proposed to exetend the Fracla component model which is a component model that uses ADL description to describe the software architecture and proposed aspect components that are components implementing a met-interface called Method interceptor. AC can be bound to ordinary components in two ways:

1. direct binding: all the methods of the aspectialized component will be intercepted by the AC
2. pointcut expression binding: pointcut expressions is needed to match the methods to be aspectized by AC.

 },
	Author = {Nicolas Pessemier and Lionel Seinturier and Laurence Duchien},
	Booktitle = {Workshop ECOOP Reflection, AOP, and Meta-Data for Software Evolution (RAM-SE'04)},
	Date-Added = {2009-02-04 15:06:43 +0100},
	Date-Modified = {2009-02-04 15:25:45 +0100},
	Keywords = {Separation of Concerns, ADL, Component, AOP, Fractal},
	Month = {June},
	Pages = {61-69},
	Publisher = {Fakult{\"a}t f{\"u}r Informatik, Universit{\"a}t Magdeburg},
	Title = {Components, ADL {\&} AOP: Towards a Common Approach},
	Year = {2004},
	Bdsk-File-1 = { }}

@inproceedings{JavaACoCoME,
	Abstract = {In this Paper CoCoME example has been modeled using Java/A Component Model.

1. Architectural View:
-----------------------------
a. The bus eventis not modeled, Instead the concept of prots is used to specify the communication between the related components
b. Controllers are modeled as ports and they are not considered as functional components
c. As Fractal Component Model, the inventory cmponent is divided into entreprise and stor components
d. The component Data::Persistence is modeled as a port

2. Behavioral View:
---------------------------
a. each port has a behavior specified as I/O transition system modeled as UML state machine
b. a componnt behavior also is modeled as I/O transition system modelded as UML state machine
c. The behavior compatibility chacking is made as follows:
      c.1. each port is checked for deadlockfreenness using Hugo/RT
      c.2. each primitive component is checked for deadlock freeness using LTSA
      c.3. behavior compatibility between a component and each one of its ports is checked using the minimization strategy of LTSA
      c.4. deadlock freeness of a composite component is checked using LTSA via checking the behavior compatibility between the linked ports of te internat components and the composite ports. },
	Author = {Knapp Alexander and Janisch Stephan and Hennicker Rolf and Clark Allan and Gilmore Stephen and Hacklinger Florian and Baumeister Hubert and Wirsing Martin},
	Booktitle = {The Common Component Modeling Example: Comparing Software Component Models},
	Date-Added = {2009-01-30 19:50:00 +0100},
	Date-Modified = {2009-03-25 14:45:57 +0100},
	Keywords = {CoCoME, Component Model},
	Month = {August},
	Pages = {207-237},
	Publisher = {Springer Berlin / Heidelberg},
	Series = {Lecture Notes in Computer Science},
	Title = {Modeling the CoCoME with the Java/A Component Model},
	Volume = {5153},
	Year = {2008},
	Bdsk-File-1 = { }}

@article{Tax2,
	Author = {Kung-Kiu Lau and Zheng Wang},
	Date-Added = {2009-01-30 10:26:55 +0100},
	Date-Modified = {2009-03-25 15:03:14 +0100},
	Journal = {IEEE Transactions on Software Engineering  },
	Keywords = {Software Components, software component models, component life cycle, component syntax, component symantics, component Composition},
	Month = {October},
	Number = {10},
	Pages = {709-724},
	Title = {Software Component Models},
	Volume = {33},
	Year = {2007},
	Bdsk-File-1 = { }}

@inproceedings{Tax1,
	Abstract = {Inthis paper, authores are introduced the problem for the lack of common terminology for CBSE i.e. there is no common definition of a component and composition operators.

The authors start descrbing the need for a syntax and a semantics also to provide a mathematical mean to describe component compositions. They also show that current component models are generaly based on the syntax of existing programming languages such as a Java or using them with mapping to IDL or use ADLs. Their semantics is the same as classes or objects or Architectural Units depends on what a component is in the model. The composition can be at the design phase and/or at the deployment phase.

the authors also shows that providing a taxonomy based on the syntax or the semantics i.e. object-based and architecture based is not meaningfull since the current component models cannot be merged together when the component models in the same categry are differents. Thus, The taxonomy proposed by the authors is based on the composition.

The taxonomy presented calssify the component models into four cathegories compared to the idealised component life cycle where components can be composed in the design and the deployment time:
1. components can be created with a builder and store them in the repository and they v-can be only composed at the deplyment time using the assembler (JavaBeans).
2. Components can be created and composed using the builder and store them composed into the repository and there is no assembler, the comonents can be only instantiated as they are at the repository i.g. EJB, COM, CCM.
3. Components can be created by the builder also they can be retrived from it and composed and store them again at the repository, there is no assembler and the components can be only instantiated as they are in the repository e.g. Koala, SOFA, KOBRA.
4. Components can be created and composed by the builder, there is no repository and no assembler, components are directly instantiated at the deplyment time.e.g. ADLs, UML2.0, PECOS, Pin and Fractal.

The aurthors justified this taxonomy by discribing the common accepted creteria of CBSE:
1. Components are pre-existing reusable software units -> Repository
2. Components can be produced and used by independent parties -> builder and assembler
3. components can be copied and instantiated -> design phase and deployment phase
4. components can be composed into composite  -> composites can be stored and retieved from the repository.

--- This taxonomy is a low leval one we neeed a higher abstracted taxonomy.  },
	Author = {Kung-Kiu Lau and Zheng Wang},
	Booktitle = {Proceedings of the 31st EUROMICRO Conference on Software Engineering and Advanced Applications},
	Date-Added = {2009-01-29 15:16:34 +0100},
	Date-Modified = {2009-01-30 09:58:15 +0100},
	Keywords = {CBSE, Taxonomy},
	Month = {August},
	Pages = {88-95},
	Publisher = {IEEE Computer Society},
	Title = {A Taxonomy of Software Component Models},
	Year = {2005},
	Bdsk-File-1 = { }}

@article{JavaA,
	Abstract = {Architectural programming is is a programming style that aims to preserve a software architecture throughout the software development process in a decent way. Java/A is an architectural programming framework that realizes that idea in Java.

Java/A is a hierarchical component model. A component in Java/A maybe a primitive or a composite, the composite component has an assembly that encapsulates compponents and their interconnections via connectors. A connector relies components through their ports. A port may has a provided and a required interface and two connectors. It may has also a protocol describing its dynamic behavior. A connector maybe a static vor a dynamic. Static ports have one instances at a time, while dynamic ones may have more than one instantce at a time. Java/A supports ordinary connectors for local communication and SOAP and RPC for remote communication. Java/A component model supports dynamic reconfiguration : creation and destruction of components, building up and removing connection between ports.

Java/A tool is a precompiler that transforms Java/A syntax to pure Java code that can be compiled directly using Javac that the compiled classes maybe integrated into Java/A framework components to be deloyed and instantiated.    },
	Author = {Hubert Baumeister and Florian Hacklinger and Rolf Hennicker and Alexander Knapp and Martin Wirsing},
	Date-Added = {2009-01-22 12:23:40 +0100},
	Date-Modified = {2009-01-22 17:37:41 +0100},
	Journal = {Electronic Notes in Theoretical Computer Science},
	Keywords = {Architectural programming, software architecture, semantics of components},
	Pages = {57-96},
	Title = {A Component Model for Architectural Programming},
	Volume = {160},
	Year = {2006},
	Bdsk-File-1 = { }}

@phdthesis{CAOP,
	Abstract = {In this thesis, the author presents a comparison of Aspect-oriented models : AspectJ, Composition filters and HyperJbased on the follwing creteria:
1. Element Symetry: The ability to define aspects are simple objects
2. Relation symetry - Placement: the ability to decrae the advices and the pointcuts in different modules
3. Relation Symetry- Scope: The ability to deal with several aspecst matching the same jointpoint

According the assessment model HyperJ was the most powerfull one with JAC.

Component Models - JBoss AOP, Spring AOP, CAM/DAOP, FuseJ - are assessed according to an assessment model  based on the following creteria:

1. Architectural Model: provide an ADL description of the component architecture
2. Model Generality: The model indenpence of any specific platform
3. Reflexivity: The ability to explore the component architecture
4. Extensibility: The ability of extending the model with some other features
5. Hirarchy: including the concept of composite components

Chapter 4 presents the Fractal Component Model with all its features, A lso its AOKell implementation is presented in detail. AOKell has two main particularities:
1. Uses aspects to glue the content part with its membrane.
2. The membrane of a component is defined as a set of components implementing the controllors.
This way a metacontrol level is introduced to the original model. The reason for which controlers are specified as components is justified by the existence of dependance between interfaces, so a controller does wok in autonomous way, it should coordinate with others in orthogonal way.

Fractal Tools are presented with their relation to the entended model:
1. Fractal-ADL: is a tool that describes components as XML balises. It also provides to describe component bindings independently from any implementation language.
2. Fractal Explorer: it is a graphical tool, it descrbes component architecture graphically and provides means to manipulate the architecture at the run-time. The author claimed that it can be used for dynamic weaving.
3. FScript: is atool that uses expressions to navigate in the architecture, it can be used for reflexivity purpose.
4.Faclet: is a framework that can be used to construct applications from their Java class implementation and some annotations added to the source code.

After that presentation, the author claimed that Fractal is the ideal tools to attend his objectives, since it satisfies his assessment model, but not the crosscutting aspects.

Chapter 6. presents how fractal model suffer from the crosscutting conecrns with an example and disscussed two main approches to reash the entende unification:
1. Heterogenous approch: Where the functionl code is described as spects, the controle and part as components and the metacontrol as objects
2. homogenous approch: Where the functional and the basic control parts are described as components in the content part and the control part as components and the meta control as objects. },
	Author = {Nicolas Pessemier},
	Date-Added = {2009-01-19 16:47:11 +0100},
	Date-Modified = {2009-01-20 12:46:34 +0100},
	Keywords = {Aspects, Components, Fractal},
	Month = {June},
	School = {Universit{\'e} Lille 1, Laboratoire d'Informatique Fondamentale de Lille, Lille, France},
	Title = {Unification des approches par aspects et {\`a} composants},
	Year = {2007},
	Bdsk-File-1 = { }}

@inproceedings{SofaVers,
	Author = {Petr Hn\v{e}tynka and Franti\v{s}ek Pl\'{a}\v{s}il},
	Booktitle = {WISICT '04: Proceedings of the winter international synposium on Information and communication technologies},
	Date-Added = {2009-01-17 13:31:44 +0100},
	Date-Modified = {2009-01-17 13:35:20 +0100},
	Keywords = {SOFA, MOF, Versioning},
	Pages = {1-6},
	Publisher = {Trinity College Dublin},
	Title = {Distributed versioning model for MOF},
	Year = {2004},
	Bdsk-File-1 = { }}

@inproceedings{SOFACoCoME,
	Abstract = {SOFA 2.0 Framewaork Features:
0. An ADL-Based design
1. The component model is defined by means of its meta-model
2. Behavior specification using Behavior Protocols BPs
3. Automatically generated connectors
4. Distributed runtime environment with dynamic update of components
5. Allow dynamic reconfiguration of component architecture
6. Supports many communication styles via connectors
7. Separates and makes extensible the extra-functional part of applications 

The Static view (i.e. the structural aspect of the component mode) of SOFA 2.0 is captured by the meat-model and its meta-classes and meta-associations. While the Behavioral view of components is Captured using Extended Behavior Protocols EBPs.

A Behavior Protocol is described as an expression buitl up frpm event tokens compined by classical regulmar operators (;, +, *) and two parrallel composition operators | and consent (i.e. detects communication errors). A Frame protocol is associated to each component frame and an architecture protocol is derived by parallel composition of frame protocols of the fisrt-level nested subcomponents. The EBPs invents using types and local varibles to the specification, also it integrates the swith and the while loop, the synchronization event operator and the consent operator that detects both bad and no activities.

Deployment is supported by SOFA 2.0 using SOFAnode destributed environement that consits of component repository and deployment docks where each deployment dock is a containner that may include several components and run them in a specific virtual machine.

The SOFA Lifecycle consists of:
1. Defining primitive components or frame components by the developer
2.  Uploads them in the repository
3. Assembly process to construct component architectures
4. A deployer assigns components to docks, sets components properties values and the control aspects to be applied in the applications in the deplyment plan
5. Connectors are generated automatically
6. Launch the appliaction
 
The compliance between components is checked using Spin, this way a EBP2PR tool is used to translate the EBP specification to Promela (i.e. PR) where each EBP is modeled as a PR process. Also, Java PathFinder (JPF) is used to check the compatibility of primitive components to their implementation code. Furthermore, a runtime vhecking against Code has been done by monitoring meth call traces during a single application run and check whether the the obtained trace is compatible with the component's frame protocol.

  },
	Author = {Tomas Bures and Martin Deck{\'y} and Petr Hnetynka and Jan Kofron and Pavel Parizek and Frantisek Plasil and Tom{\'a}s Poch and Ondrej Sery and Petr Tuma},
	Booktitle = {The Common Component Modeling Example - Comparing Software Component Models},
	Date-Added = {2009-01-13 09:19:07 +0100},
	Date-Modified = {2009-01-13 14:41:34 +0100},
	Keywords = {CoCoME, SOFA},
	Month = {August},
	Pages = {388-417},
	Publisher = {Springer Berlin / Heidelberg},
	Series = {Lecture Notes in Computer Science},
	Title = {CoCoME in SOFA},
	Volume = {5153},
	Year = {2008},
	Bdsk-File-1 = { }}

@techreport{SOFAConnectors,
	Abstract = {In this paper, connectors are defined as first class entities capturing communication among components. A connector has an architecture described in terms of elements and binding elements. An element architecture maybe a pritive or a composite element. Each element has ports. Ports are either local ports aor remote ports. Binding between the elements in the architecture is always remote while it is always local between inter-element. Remote binding is bidirectional. 

Coonectors differ from being ordinary components because:
 1. Connectors are typically span different adress space where a component is local.
 2. Connectors have a different lifecycle than components (i.e. they are created before component deployment)
 3. Connectors are templates (i.e. They use variable signatures also called formal signatures to be adated to actual signatures) and component are specific.

 A connector generator is mainly composed of :
   1. Architecture resolver: creates connector configuration
   2. element generator : adapts element templates to particular interfaces.

The Architecture resolver assures three main requirement consistencies:
  1. Cooperation: elements in a connector configuration understand each other.
  2. Environment: An element can work with a target environment.
  3. Connection requirement: connector configuration reflects all connection requirements. 

},
	Author = {Tomas Bures},
	Date-Modified = {2009-01-12 21:58:09 +0100},
	Institution = {Department of SW Engineering, Charles University, Prague},
	Keywords = {Connectors, Components, Heterogeneous Deployment},
	Month = {August},
	Number = {2005/4},
	Title = {Automated Synthesis of Connectors for Heterogeneous Deployment},
	Year = {2005},
	Bdsk-File-1 = { }}

@inproceedings{SofaController,
	Abstract = {Asbaco: Aspect-Based Controller introduces the concept of microcomponent.

General Features:
-------------------------
1. Easly combine different controller extensions
2. Easy to select individual component instances to which the extensions will be applied
3. Encapsulate the copntroller functionality independently from the the busniss code of the component
4. Capture bindings betweeen the controller extensions and the component controller.

A Microcomponent does not have a controller part and other subcomponents, A Micricomponent is a minimal component that contains a set of client and server interfaces for the binding purpose. Those interfaces are related either to the coresponding interfaces of other microcomponents ot to an external interface of the host component (i.e. the component that includes the microcomponent). A microcomponent may also has one client and one server interfaces designed as delegate interfaces to capture the common pattern of a delegation chain.

While intercepting a control interface is straightforword (i.e; a microcomponent is created for each control interface type and inserted to the delegation chain), intercepting a functional interface needs the dynamic microcomponents that can be generated for each interface type intercepted. 

A control component is used to faclitate control part extension, this control component is bound to a client control interface of the host component. This way, microcomponents can access to the control component offered services.

In Asbaco prject controllers can be extended via aspects. An aspect in Asbaco is an xml specification that contains the different part definition:
 
  1. The Aspect name
  2. Frame-addons : collction of control interfaces to be introduced into a component.
  3. Microcomponent definitions
  4. Dynamic microcomponent definitions
  5. Component selectors : join points - the components to be affected by the aspect
  6. Interface seletors: The interfaces to be affected by the aspect
  7. microcomponent instantiation
  8. Binding

The advices are specified using launch configuration file that specifies the aspects to be applied, the application components and the targer for each aspect. Also aspectes can be applied to other aspects in Asbaco.

  },
	Address = {Washington, DC, USA},
	Author = {Vladimir Mencl and Tomas Bures},
	Booktitle = {APSEC '05: Proceedings of the 12th Asia-Pacific Software Engineering Conference},
	Date-Added = {2009-01-06 14:08:19 +0100},
	Date-Modified = {2009-01-12 18:45:56 +0100},
	Keywords = {Component Model, Component Controllers},
	Pages = {729-737},
	Publisher = {IEEE Computer Society},
	Title = {Microcomponent-Based Component Controllers: A Foundation for Component Aspects},
	Year = {2005},
	Bdsk-File-1 = { }}

@techreport{sofaMM,
	Abstract = {In this paper a specification of an example using SOFA is made, and the Removing Component Pattern is presented.

The control part of SOFA is modeled as a single provided interface that manages the component life cycle.

Removing Component Pattern : Components van be freely removed from the architecture at runtime, the only issue is the unbound required interfaces that results from the removing. But the authors claimed that there is no problem in SOFA because the component environment can verify whether the required interfaces can be left unbound or not. Connection removing is only allowed as a result of component removing. 

The Control part of a SOFA 2.0 Component is modeled as a set of microcomponents that are flat (i.e. no nested microcomponents) and recursion-free (i.e. no control part of microcomponents). Each microcomponent exposes a set of control interfaces such as lifecycle and binding. Other functionality of the control parts are added to the components as aspectes at deployment time.},
	Author = {Petr Hn{\v e}tynka and Franti{\v s}ek Pl{\'a}{\v s}il and Tom{\'a}{\v s} Bure{\v s} and Vladim{\'\i}r Mencl and Lucia Kapov{\'a}},
	Date-Added = {2009-01-06 13:16:33 +0100},
	Date-Modified = {2009-01-06 14:08:04 +0100},
	Institution = {Department of SW Engineering, Charles University, Pargue},
	Keywords = {Metamodel, SOFA},
	Month = {December},
	Number = {11/05},
	Title = {SOFA 2.0 Metamodel},
	Year = {2005},
	Bdsk-File-1 = { }}

@inproceedings{DynConfig,
	Abstract = {This paper adresses two main problems in hierrachical component based systems:

1. Dynamic Reconfiguration : Adding/removing a component, Adding/removing a connection and Adding/removing a component's interface.
The authors in the paper claimed that replacing a component with another one with a compatible interface is easy in SOFA and SOFA 2.; And they justified that by the fact that all the changes are located in the updated component and are transparent to the rest of the application. Also they said, that dynamic update should be done by external enties than the application itself (i.e. the user, the provider, etc.) and a sequence of these operation leads to the evolution gap problem (i.e. uncontrolled architecture modification).

The evolution gap problem in SOFA 2.0 is avoided by limiting the dynamic reconfiguration to those are compliant with specifc reconfiguration patterns : nested Factory, component removal and utility interface.
       1.1. Nested Factory Pattern: The newly created component B becomes a sibling of the component A that initiated the creation. This way, the collaboration with B becomes easier and the provides a better perfermance.

 2.      1.2. Utility Interface Pattern: Is used when a component provides a functionality that is used by multiple components at different levels of nesting. In that case, the reference to such service is passed freely among components and the connection made using this reference is estabilished orthogonally to the architecture hierarchy. Using this pattern the result component models becomes an ordinary service-oriented application. 
},
	Author = {Petr Hn{\v e}tynka and Franti{\v s}ek Pl{\'a}{\v s}il},
	Booktitle = {Proceedings of CBSE 2006, Vasteras, Sweden},
	Date-Added = {2009-01-06 10:07:59 +0100},
	Date-Modified = {2009-01-06 11:23:14 +0100},
	Keywords = {Dynamic reconfiguration, services access, hierachical component models},
	Pages = {352-359},
	Publisher = {Springer-Verlag},
	Series = {Lecture Notes in Computer Science},
	Title = {Dynamic Reconfiguration And Access to Services in Hierarchical Component Models},
	Volume = {4063},
	Year = {2006},
	Bdsk-File-1 = { }}

@inproceedings{Sofa2.0,
	Abstract = {SOFA 2.0 is an exyension version of SOFA which is a hierarchical component model that supports both primitive and composite components, each component is defined by its frame and architecture:

1. Frame: black box describes the provided and the required interfaces of the component
2. Architecture: Gray-box describes the the subcomponents and their interconnections

Components are connected using first class-entities called connectors and the component behavior is descibed formally via behavior protocols.

The runtime structure of the component is composed of the control part (i.e. component manager) and the functional part (i.e. code of the component and/or of its subcomponents).

The development lifecycle of a SOFA system consists of:
1. ADL descriptions of the system to generate skeletons
2. implements the primitive components by adding their code
3. add the developed components to a repository
4. describe a plan for the deployement
5. execute the deplyment plan and launch the execution

The problems behinds the above specification of SOFA are:

1. Limit support to dynamic reconfiguration: adding, removing components at runtime. Forbidding it is not feasible and allowing arbitrary ones at runtime is not appropriate which leads to uncontrolled modification.

2. No structure for the control part of the component: controllers are provided interfaces that describes the non functional part of the component: lifecycle, reconfiguration, etc. The problem with the controllers are not well structured and not extendubale.

3. unbalanced support for multiple communication styles: Supporting different communication styles needs the connection to be defined as first-class entity. SOFA supports four styles: method invocation, message passing, streaming, abd distributed shared memory but they are not well integrated with other SOFA abstractions.

SOFA 2.0 uses Meta Object Facility (MOF) meta models to design the component system and generate skeletons and it doesn't use ADL as SOFA. ADL and MOF ave different abstraction levels. MOF meta models can be used to genrate skeletons, to deploy components and to launch the execution at the runtime. 

SOFA 2.0 meta model is presented as a class diagram in UML, each class describes a different aspect of the model. 

SOFA 2.0 only permit dynamic reconfigurations done in accordance to a predefined reconfiguration patterns such as: nested Factory, component Removal and utlity interface. Using these patterns prevent an uncontrolled modification of an architecture.

SOFA 2.0 models controllers as microponents (i.e. classes implementing a specific interfaces) which are minimals (i.e. no nested microcomponents, no connectors featured and no extensible or structured control part) . The poposed microcomponents are defined in aspects that contains their difinitions and their instantiation pattern. Applying several aspects leads to desired functionality. In the current version of SOFA 2.0 there is a core aspect which is present in all controllers this aspect manges the component lifecycle and binding controller. 

SOFA 2.0 distinguish two kinds of connectors : design and runtime connectors. Design connnectors are already supported by SOFA, they repesents edgesbetween different interfaces with their communication styles and features. Runtime controllers are the code artifacts at runtime to automatically genrate the design controller. This way the design controller are generated at the deployement level just before the application is launched.  This way the connector code can be optimized according the configuration of the site where the component is deployed.
  },
	Address = {Washington, DC, USA},
	Author = {Tomas Bures and Petr Hnetynka and Frantisek Plasil},
	Booktitle = {SERA '06: Proceedings of the Fourth International Conference on Software Engineering Research, Management and Applications},
	Date-Added = {2008-12-15 11:37:27 +0100},
	Date-Modified = {2008-12-15 16:32:16 +0100},
	Keywords = {Component Model, SOFA, Hierarchisation},
	Pages = {40-48},
	Publisher = {IEEE Computer Society},
	Title = {SOFA 2.0: Balancing Advanced Features in a Hierarchical Component Model},
	Year = {2006},
	Bdsk-File-1 = { }}

@inproceedings{CoCoME,
	Author = {Sebastian Herold and Holger Klus and Yannick Welsch and Constanze Deiters and Andreas Rausch and Ralf Reussner and Klaus Krogmann and Heiko Koziolek and Raffaela Mirandola and Benjamin Hummel and Michael Meisinger and Christian Pfaller},
	Booktitle = {The Common Component Modeling Example - Comparing Software Component Models},
	Date-Added = {2008-12-04 14:10:02 +0100},
	Date-Modified = {2008-12-05 20:24:11 +0100},
	Editor = {Andreas Rausch and Ralf Reussner and Raffaela Mirandola and Frantisek Plasil},
	Keywords = {CoCoME},
	Month = {August},
	Pages = {16-53},
	Publisher = {Springer Berlin / Heidelberg},
	Series = {Lecture Notes in Computer Science},
	Title = {CoCoME- The Common Component Modeling Example},
	Volume = {5153},
	Year = {2008},
	Bdsk-File-1 = { }}

@inproceedings{FractalCoCoME,
	Abstract = {The benifits of applying Fractal component model to CoCoME is twofold: 
1. Verification of composition correctness with respect to their behavior specification using BP (Behavior Protocol) Checker
2. verification of the correspondence between code and behavior specification using Java PathFinder tool
Also it generates code skeletons from the model and runtime monitoring.

The problem occured with Fractal are:
1. Does'nt support message buses.
2. Does'nt adress the deployment related issues

Architectural Changes:
-------------------------------
1. The evantBus component is partitioned into two independent buses.
2. GUI and Application components are replaced by StoreApplication and ReportingApplication
3. Explicitly distinguish between the EnterpriseServer and the ProductDispatcherIf and the MoveGoodsIf

Behavioral Changes:
-----------------------------
Fractal uses behavior protocols to describe the component behaviors in order to check the compatibility between the specification and the implementation. Due to the none compliant between the UML specification and the implementation in the CoCoME assignement (i.e. non countinuation of the payment process after erroneous credit card payment and the missing of the UC8 implementation) and the missing of state machines.

1. Doesn't implement the actor behaviors
2. Proposed two alternatives of protocols one according to the UML specification and one to the implementaion model.

Deployement Changes:
--------------------------------
1. use FractalRMI rather than Sun RMI
2. Doesn't support JMS to implement buses, rather it used two components for routing messages and the remote communication is implemented using FractalRMI
3. Deployment is planned using Fractal ADL and implemented using FractalRMI

Implemenation process:
--------------------------------
1. The architecture is modeled using FractalGUI
2. the resulting model is extended by hand to integrate behavior protocols
3. A tool is used to get the skeleton of the appliaction
4. The code of the CoCoME implementation is adapted and insered to the corresponding components

Testing Process:
-----------------------
Fractal uses FracalBPC to check whether a Component C, when the appliaction is running, communicates with other components with respect to the behavior protocol specification.

Some considerations are taken in order to speed up the process:
1. The GUI components are not considered for testing
2. Extra-functional proprieties are independently tested from the functionality testing
3. The tarding system is automatically lunched. },
	Author = {Lubom\'{\i}r Bulej and Tomas Bures and Thierry Coupaye and Martin Deck{\'y} and Pavel Jezek and Pavel Parizek and Frantisek Plasil and Tom{\'a}s Poch and Nicolas Rivierre and Ondrej Sery and Petr Tuma},
	Booktitle = {The Common Component Modeling Example - Comparing Software Component Models},
	Date-Added = {2008-12-04 11:38:26 +0100},
	Date-Modified = {2008-12-10 18:02:58 +0100},
	Editor = {Andreas Rausch and Ralf Reussner and Raffaela Mirandola and Frantisek Plasil},
	Keywords = {Fractal, CoCoME},
	Month = {August},
	Pages = {357-387},
	Publisher = {Springer Berlin / Heidelberg},
	Series = {Lecture Notes in Computer Science},
	Title = {CoCoME in Fractal},
	Volume = {5153},
	Year = {2008},
	Bdsk-File-1 = { }}

@inproceedings{VirtCls,
	Abstract = {In this paper Virtual calsses and their semantics and their soundness test are presented.

Main Concepts:
---------------------
1. A virtual class provides a means to extend the representation and the operations of a data abstraction (i.e. extensiblity problem or expression problem) and provides a higher-order hierarchies in which a hierarchy maybe send as paramater or returned as a result of a method execution
2. A family is a collection of classes that depends each others
3. A family can be extended and subclassing the class in which it is defined
4. Overriding of virtual classes is also possible within virtual classes of a family
5. The static path of a class definition is the lexical adress of a class defined by the list of names of lexically encolsing class definitions
6. The reference to classes are late bound
7. A virtual class may have many superclasses
8. out keyword is used to refer to the object enclosing the class
9. Two types are only compatible if they have an identical enclosing objects
10. Family polymorphism is supported by virtual classes. 

An informal language of vc is presented, a formal one also is introduced and a mapping from informal to informal is described. Also some auxiliory definitions are presented. A Mixin is defined as static path of a class.},
	Address = {Charleston, South Carolina, USA},
	Author = {Erik Ernst and Klaus Ostermann and William R. Cook},
	Booktitle = {POPL'06},
	Date-Added = {2008-11-29 19:16:07 +0100},
	Date-Modified = {2008-11-29 22:04:18 +0100},
	Keywords = {Virtual classes, Soundness},
	Month = {January},
	Pages = {270-282},
	Publisher = {ACM},
	Read = {Yes},
	Title = {A Virtual Class Calculus},
	Year = {2006},
	Bdsk-File-1 = { }}

@inproceedings{CaesarJ,
	Abstract = {CesarJ introduces two interessting concepts:

1. Class Family: is a unit which encapsulates other classes called virtual classes. The result unit maybe inherited such that, the virtual members maybe refined. Each reference to virtual member is annotated with a path to its owner family object.

2. Family polymorphism : a method or a sate can be defined generically so that it can refer polymorphically with different families. 

In CaesarJ classes can be composed using the mixin operator &. That composition operator realizes a variant of multiple inheritance that linearizes the superclasses.

In CaesarJ classes maybe declared abstract. An abstract class may conatin either abstract or concret members and a concrete class may have an abstract method declaration such that a method can be abstract when at least one of its enclosing classes is abstract.

Abstract classes are used as interfaces enabeling a fine-grained separation of the different concerns. That means that an abstract class also called collaboration interface may define one or more facets where each facet is implemented in another abstract class that inherit the first one. Composing those abstract classes implementing different facets in one concret class provides the complete design. 

A Family class which implements a component facets by adapting external classes is called binding. So that, concret family classese can be produced by combining bindings with the families implementing the component functionality to be integrated.

Bindings map between types from two domains is called wrappers. Wrappers are created by wrapper constructors which takes the object to be wrapped as a parameter and return the corresponding wrapper object which is unique. Bindings just implements the structural mapping, behavioral mapping in CasearJ is implemented using AspectJ-like pointcuts and advices.

Wrappers with the same name build inheritence heirachies, which reflect the inheritence hierarchies of their wrappees.

The collaboration interface provides a contract for the composition: The methods signatures of the component implementations are the same with those used in component bindings, Also the class names are unique when they are shared between the different kind of components.

An aspect in CaesarJ is a component that inherits its pointcuts and advices from its component binding. This component is as an object, it can be instantiated and send as a parameter. This way aspects can be used in a specific scope (i.e. local deployment) by using the deploy and the undeploy constructs. Also aspects here can be garbage collected when they are not referenced anymore and they are not deployed. Aspects also can be deployed by limiting their scopes into a single thread in a multithreading environement but this doesn't work well in event-driven environement. 

Aspects can be statically deployed either by declaring the class implementing the aspect as deployed or to declare as a deployed final attribute in the application class. This way the aspect will be activated at the loading time.

Aspects also can be remotely deployed using a specific CaeserJ API which is integrated as an RMI infrastructure in Java. Also deployement on a distributed control flow is possible in CasearJ using API calls to deployOnControlFlow and undeployFromControlFlow methods.

CaesarJ implementation model:
-----------------------------------------
1. Virtual class implementation:
------------------------------------------
  CaesarJ transforms all the virtual classes into Java classes as compile time as follows:
         1. Generates the type graph describing implicit and explicit types and relations declarations
         2. For each type contained in the type graph it calculates its mixin using the mixin algorithm
         3. The generated mixin lists are transformed into Java languge constructs
                3.1. each cclass declaration is transformed into an interface and a Java class that implements the corresponding interface
                3.2. mixins are used for each type to ensure simple inheritence between genreted classes, sometimes mixin copies are used to ignore conflicts  

2. Wraper implementation :
------------------------------------
Wrapers are transled to virtual classes that are identified by the paors of wraper and wrapee names. Wrapers can be overriden in the sub-family by declaring a new wrapper with the same name and for the same wrapee class.

},
	Author = {Ivica Aracic and Vaidas Gasiunas and Mira Mezini and Klaus Ostermann},
	Booktitle = {Transactions on Aspect-Oriented Software Development I},
	Date-Added = {2008-11-24 12:43:10 +0100},
	Date-Modified = {2008-12-03 13:25:40 +0100},
	Keywords = {Component Model, aspects and components, CaesarJ},
	Month = {February},
	Pages = {135-173},
	Publisher = {Springer Berlin / Heidelberg},
	Series = {Lecture Notes in Computer Science},
	Title = {An Overview of CaesarJ},
	Volume = {3880},
	Year = {2006},
	Bdsk-File-1 = { }}

@inproceedings{FuseJ2,
	Abstract = {In this paper as the Ceasar component model, aspects and components are considered as unique entities, they require services and provide other services. They only differ in the way which the components interact with each others. Gates and a gate language is intoduced to allow users access to their internal behaviors. As such, a component interface my define one or more gates describing the access of its behaviors. A gate is defined for binding one or more services. 

Each gate is responsible itself for specifying whether it can receive incoming communication (i.e. inputgate) , trigger outgoing communication (i.e. outputgate) or both (i.e. gate).

The gate languge describes two main constructs:
1. binds: the signature of the component serives
2. exposes: describes the properties of the gate, such as the input arguments and the return value. It is similar to the inter-crosscut variables in EAOP.

Connectors and a connector language also is provided to combine one or more gates and describe how this gates shoul interact. The connector specification is divided into two parts:

1. connection part: specifies the two gates that shouls be connected using execute-for construct.
2. Mapping part: specifies where the interaction should be made. It can be defined by mapping gates properties. 
Additional when clause is assciated to the connectors specifying aspects interactions to specify when the interaction should be made. 

FuseJ model also provides two implementation components: 
1. Gate interface Preprocessor: that translates the defined gates to Java annotations in the content of the component to make it a container of it self.
2. Execution environement: which is the responsible for managing the deployment of both components and connectors. When a component is deployed an automatic containner is generated based in the notations described internaly by the gate interface preprocessor. The containner automatically installs the gates. After that the component is activated to be ready for interaction. When a connector is deployed the JavaBean that manges the interaction between the involved gates is automatically generated.

The FuseJ model has evaluated by analysing four main software engineering properties:
1. Comprehensibility: is enhenced by modularizing aspects and components as independent deployable components with the same dimension which allow to understand the cflow of the appliaction.
1. Predictability: is less in FuseJ model because each component describes by itself the set of  joinpoints and the other components can only intiate communication on those points.
3. Evolvability: FuseJ supports the incremental development of component-based appliactiosn by allowing attachment and detachment of components at run-time. Also it supports the evolution of a single component.
4. Semantic Interaction: FuseJ doesn't support semantic interaction between components.


 },
	Author = {Davy Suv{\'e}e and Bruno De Fraine and Wim Vanderperren},
	Booktitle = {Software-engineering Properties of Languages and Aspect Technologies Workshop AOSD},
	Date-Added = {2008-11-21 18:04:20 +0100},
	Date-Modified = {2008-12-03 10:25:20 +0100},
	Keywords = {Aspect-Oriented Software Development, component-Based Software Development, Unification},
	Title = {FuseJ: An architectural description language for unifying aspects and components},
	Year = {2005},
	Bdsk-File-1 = { }}

@inproceedings{FuseJ1,
	Abstract = {In this paper, authors describes a component model called FuseJ that consides aspects as ordinary components that can be composed to other components using configurations. A configuration is an abstract language that can be used to specify which service (target services) can be composed to other service (source service) under which context mapping (property mapping) with some p^reconditions (condition specification). The aspect services are composed to ordinary services using the constructs : before, after and around strategies. This kind of composition is encapsulated in a configuration by a so-called linklets. The result of the composition is a new component that can be composed with others this provides a hierarchical component model. 

As JAsCo, there is no static composition, the aspect code is not merged with the base code. The composition is abstract. The aspect combination is not specified and around case is not well clarified.},
	Author = {Davy Suv{\'e}e and Bruno De Fraine and Wim Vanderperren},
	Booktitle = {CBSE: Component-Based Software Engineering},
	Date-Added = {2008-11-21 17:21:57 +0100},
	Date-Modified = {2008-11-21 18:11:00 +0100},
	Keywords = {Aspect-Oriented Programming, Component Model, FuseJ, Symmetric approach},
	Month = {June},
	Pages = {114-122},
	Publisher = {Springer Berlin / Heidelberg},
	Series = {Lecture Notes in Computer Science},
	Title = {A Symmetric and Unified Approach Towards Combining Aspect-Oriented and Component-Based Software Development},
	Volume = {4063},
	Year = {2006},
	Bdsk-File-1 = { }}

@conference{JAsCo,
	Abstract = {JAsCO is an aspect-enabled component model, this model allowed to describe aspects as independent entities that can can be reused with other applications. JAsCo introces two main concepts:

1. Aspect beans: are regular Java beans that can be used to declare one or more logically related hooks.
2. Hooks : are generic and reusable entities similar to abstract pointcuts and advices. The initialization of a hook with a specific contex is made using the so-called connectors.

The main features of JAsCo are:

1. Aspects are totally reusable: they don't need any adaptation to be used for different applications.
2. Allows plug-and-play of aspects at runtime
3. Aspects don't across business code. 

JAsCo Syntax:
--------------------

Aspect Syntax:

An aspect is a simple java class that may declare members and methods but it alos allowed the declaration of hooks. A hook is declared using "hook" keyword followed by a name. Ahook has a constructor like ordinary class contructors used to specifiy when yhe aspect should be involved. Many constructors may apear for the same hook. A hook constructor may has one or more abstract method as parameters. The hook constructor body describes how the join points of a hook initialization should be computed. This is similar to use pointcuts in AspectJ. The hook body defines advices before, after and replace.

Connector Syntax:

Conectors are used to deply aspects. A connector is an independent entity which instantiate one or more hooks and by calling their constructs it initializes them. After initialization a sequence of adices calls may appear. It they not, all the advices defined in the hook will de executed in the order of before, replace and after. This way if more than when hook matches the same join point the developer can define the order used to execute the corresponding advices.

Other aspect combination strategies can be added by defining a general interface called CompinationStrategy that defines the method verifyCombinationstrategy that has a list of hooks as a parameter. The developer should declare a class that implements that interface and specify how the hooks have to be executed. At the connector declaration the appliacble hooks are instantiated and added to the hook list using addCombinationStrategy method. Many than one strategy can used. In that case, the result of the first strategy is passed to the second and so forth.

The idea behind JAsCo beans component model is that regular java beans components are transformed into JAsCo beans components at the developement time. Then a component developer can use an aspect enabled JAsCo beans for integrating them in his design. In the JAsCo model a connector registry is defined to be the intermediate between components and connectors, in such way, the connector registry should be notified when a trap has been reached or a connector has been loaded. Traps are defined for each method to defere the execution to the connector registry. This latter contains a database of connectors, in such way, when a trap is reached the registry looks up all the connectors in the database that are concerned by the execution of the corresonding method call. The connector in turn dispatches it to the hooks that have been instantiated with the corresponding method or event. 

 },
	Address = {Boston, Massachusetts},
	Author = {Davy Suv{\'e}e and Wim Vanderperren and Viviane Jonckers},
	Booktitle = {AOSD'03: Proceedings of the 2nd international conference on Aspect-Oriented software development},
	Date-Added = {2008-11-18 13:33:11 +0100},
	Date-Modified = {2008-11-19 11:18:15 +0100},
	Keywords = {Aspect-Oriented Programming, Component Model, JAsCo},
	Pages = {21-29},
	Publisher = {ACM},
	Title = {JAsCo: an Aspect-Oriented approach tailored for Component Based Software Development},
	Year = {2003},
	Bdsk-File-1 = { }}

@conference{AspAsComp,
	Abstract = {The authors in this paper introduces an adaptation version for UML Component models that supports aspects as crosscutting components. The crosscuting components as orinary components have providrd interfaces called crosscutting interfaces and requires services from orinary components, also called busniss components. The semantics of the presented model is that each operation in a buniss components that is crosscutted by the crosscutting interface of a crosscutting components we will generate a copy of this one with the name do_opname() and change the orignla code to call de_opname() and after that calls the crosscutting operation registerExecutedOperation().

A new implementation model called JAsCO syntax is introduced within an example. A crosscutting aspect is defined as a class which implements the  registerExecutedOperation. Also a hook is used to describe the pointcuts and the advices to be used in abstract way as possible. The connector create an object of the crosscut component class and specifies which methods are involved as well as the advices to be invoked : before, after ar both. This way the crosscut component can be reused in different applications, the only think that we should to specify is the connector code. 

},
	Author = {Marcelo Medeiros Eler and Paulo Cesar Masiero},
	Booktitle = {Reuse of Off-the-Shelf Components},
	Date-Added = {2008-11-18 11:36:18 +0100},
	Date-Modified = {2008-11-18 13:17:11 +0100},
	Keywords = {aspects and components},
	Month = {July},
	Number = {4039},
	Pages = {411-414},
	Publisher = {Springer Berlin / Heidelberg},
	Series = {Lecture Notes in Computer Science},
	Title = {Aspects as Components},
	Year = {2006},
	Bdsk-File-1 = { }}

@article{aspOfComp,
	Abstract = {In this paper, the authors showed how EJB component model (i.e. all the containner component models such as CORBA) implements the non functional code  (i.e. infrastructural services). The infrastructural services provided by the EJB container are with the bean by editing the bean's deployement descriptor which is a file which contains a declaration of such infrastrucutral services that should be considered by the home container that controls the EJB Object has an XML format. Also, interceptors used by JBoss and also supported by EJB play the role of separation of concerns

Limitations:
 1. Lack of Tailorability: It is not possible with EJB to configure the container or any of its infrastructural services and it does not provide a mechanism to to add new services to the container.
- The EJB specification treats the container as a black box which implies that the specification does not allow configuring interceptors or adding custom interceptors and extending the container functionality.

2. Lack of Checking and Enforcement : An EJB developer has to obey many design rules and idioms (i.e. 17 programming restrictions are defined in the EJB specification) that are not enforced and cannot be always checked by the compiler.  (e.g. Type checking).

3. Insufficiency: We cannot associate services provided by a containerwith ordinary classes independent of the EJBs in whose context the Java classes live.

The authors also shows how aspects in term of AspectJ can be used to associate infrastructural services to the base objects. Then some problems in using aspects are discussed:

1. Reusing aspects: Reusing aspects in AspectJ can only be implemented by defining  abstract aspects which have some limitaions:
         a. The inheritence hierarchy between conceret and abstract aspects complicates the understandability and the maintability of such systems.
         b. The source code of the abstract aspect should be avaliable at the design time to allow developers to bind them with the concrete aspects and the base objects
         c. Applying abstract aspects is limited especially if aspects define aspect state.

2. Deploying aspects: Aspects are weaved to the base objects at compile time which decreases the flexibility and the reusability significantly. While the EJBs supports run time deployement of the infrastructural services.

At the end of the paper, the authors presented the main features that the new generation of the technology of separating crosscutting concerns that are:

1. The need of a language that supports components as they are and not to map components to objects.
2. The new generation should support aspectual polymorphism, that is the infrastructural services will be late bound to the functionality of the components following the runtime context i.e. hot deployment.
3. The new generation of the AOP should provide means to the aspects to be deployed at runtime as the component descriptors. The deployement should be declarative for both ordinary objects and components.

A Caesar model has introduced and disscussed shortly how it adresses the main problems identified with AspectJ:

1. Reusability: In Caesar aspect implementations (i.e. abstract aspects) and bindings (i.e. concrete aspects) are defined separately in different program units and they can be related to each other using a collaboration interface. In such way different bindings can be composed to different implementations of the same collaboration interface.

2. Deployment and Aspectual Polymorphism: pointcuts and advices in Caesar are passive and they can be activated using "deploy" clause. That way, aspects can be deployed before their pointcuts and advices become effective.},
	Author = {Roman Pichler and Klaus Ostermann and Mira Mezini},
	Date-Added = {2008-11-17 14:19:33 +0100},
	Date-Modified = {2008-11-19 15:28:17 +0100},
	Journal = {Software-Practice and Experience},
	Keywords = {Aspect-Oriented Programming, Components, EJB},
	Month = {March},
	Number = {10},
	Pages = {957-974},
	Title = {On aspectualizing component models},
	Volume = {33},
	Year = {2003},
	Bdsk-File-1 = { }}

@inproceedings{CORBA,
	Abstract = {A Corba Components Type = Attributes + Ports + Base reference

The base reference is used to distinguich the component types from each other in a CCM Assembly.

Attributes are used to the component configuration purpose.

Ports are used as access points to the services of the components, four kind of ports are available :
1. Factes: A Facet describes the interface provided by the component. The facet implementation is encapsulated within the component. A Facet has several copies of its reference to be used when many clients use the same Facet.

2. Recepteacls : describes the interfaces required by the component. It allows a component to accept an object refernce in order to use its provided operations, it is also used to build assemblies. Two kinds of receptacls are available:
       2.1. Simple Receptacles: only one reference can be connected at a time
       2.2. Multiple Receptacles: Many references can be conneceted simultaniousely, when the maximum number of providers can be specified at the implementation level.

3. Event Sources: are used to throw events to provider components in asynchronous way and they are two kinds:
       3.1. Emettors: dealing with simple connections.
       3.2. dealing with multiple connections

4. Event Sinks: are used to recieve events from clients in an asynchronous way.

Only simple inheritence is allowed between component types but they can support multiple interfaces.

A Corba Component Model (CCM) provides two kinds of components : Basic and extended which they differ in the capabilities they can offer. The basic component has only attributes, cannot iniherit from another component, cannot provide or use interfaces and cannot make event declarations.


A component home is associated to one or more component types to mange their instantiation their life cycles. Many component homes can manage the same component type but with different instances. There are two kinds of component homes: Keyless and Primary key based homes. they differ from each other by the manner they access to their manged instances with keys or not. 

Component configuration is divided into two different parts: Initialization and use. The initialazation is supported using objects encapsulating the comonent attributes providing set access operations to modify their values.       

In CORBA designners shuld describe their component system using CCM IDL 3 language. A maping rules are provided  to automatically mapp the IDL 3 definitions to the IDL 2 definitions which can be used by developpers to describe the implementation part of the components.},
	Author = {Group, Object Managmenet},
	Date-Added = {2008-11-04 10:57:14 +0100},
	Date-Modified = {2008-11-09 16:23:06 +0100},
	Keywords = {Component Model, CORBA, Model},
	Month = {April},
	Number = {Version 4.0},
	Organization = {Object Managmenet Group},
	Title = {CORBA Component Model Specification},
	Year = {2006},
	Bdsk-File-1 = { },
	Bdsk-File-2 = { }}

@inproceedings{StatfAspects,
	Abstract = {This paper proposes an extended version of the formal framework proposed in Douence'02. The extended version of the framework propsed three main features to be extended the original version:

1. inter-crosscut variables: Variabels are used to pass values between crosscuts. This way, when a crosscut matches the current join point, the substitution found is applied to the rest of the aspect.

2. Aspects composition operator is generalized : A sequential composition operator is added to specify that an aspect aspect A1 is executable until a crossut C matches a join point then A1 stops and another aspect  A2 starts. Furthermore, compositions adaptors are introduces to specify what should be done if two aspects interact, this way composition is described as: A1 IIo A2 where o is the adaptor which is described using a language similar to that of aspects with unary and binary transformers to specify what to do with the aspects inserts. This way, an adapted aspect composition A= A1 IIo A2 behaves like A1 II A2. The difference is if only one aspect matches, u is applied to its insert , and if the two aspects match, b is applied to the interact. Furthermore, strong independence can be tested too for the adapted composition, to achieve this, a new propagation rule is defined for it. 

3. Applicability conditions for aspects are defined as requirements:  A requirements are proposed to specify the base programs that the aspect is applicable for. This way, the requirements is checked before the aspect is woven to the base program which make aspect oriented programming safer. Requirements are defined as aspects that should be executed in parallel wthin the aspect. If two composed aspects needs the same requirement, this later is executed in parallel to the composed aspect. The prcocess for checking requirements is as follows:
   1. Base programs are described as a sequence of traces of abstract join points
   2. A specialization algorithm Spec is applied to the composed aspect of the parallel composition of the aspect to be woven and the requirement and the base program.
   3. Simplification is made based on the defined laws
   4. If the command abort(), which is a part of the requirement specification, does'nt occurs after the simplication, that means that the program satisfies the aspect requirement ans as a result the aspect can be woven safelly, otherwise the programmer should either choose another aspect to apply or modify the base program so that it satisfies the aspect requirement.},
	Address = {Lancaster, UK},
	Author = {R{\'e}mi Douence and Pascal Fradet and Mario S{\"u}dhot},
	Booktitle = {AOSD'04: Proceedings of the 3rd international conference on Aspect-oriented software development},
	Date-Added = {2008-10-29 15:24:43 +0100},
	Date-Modified = {2008-11-03 11:30:41 +0100},
	Editor = {ACM Press},
	Keywords = {Composition, Reuse, Interaction Analysis, Stateful Aspects},
	Month = {March},
	Pages = {141-150},
	Publisher = {ACM},
	Title = {Composition, Reuse and Interaction Analysis of Stateful Aspects},
	Year = {2004},
	Bdsk-File-1 = { }}

@inproceedings{DetectAspects,
	Abstract = {Aspect interaction problem is the main issue adressed by this paper. The others contributed with presenting a formal expressive crosscut language, two static conflict analyses and some languistic support for conflict resolution. The propsed work promises the development of an automatic tool for detcting conflict interaction between aspects, even if they are developped independently. Also provides a composition language that can be used by the programmer to resolve the indicated conflict cases by the analyzer.

 The proposed framework is based on observable execution traces. This later is defined as a transition relation denoted by -> between observable exection states which are configurations of the form (j, P, \segma) where j is the current join point, P is an abstraction of the static program and \segma is the the dynamic execution state. Spetial join points representing the entry and the exit of the program are denoted respectivelly by I< and I>

An aspect in the proposed framework is constituted of a set of rules C > I where C is called crosscut which is used to match join points and I is called inserts which described the code to be executed when the crosscut C matches the join point. 

A crosscut is defined formally as a conjunction, a disjunction and a negation of terms. A term is defined as a variable or a symbol with a sequence of other terms. An insert is defined as a term. The application of a crosscut to a joinpoint is described as C j = fail if the matching is failed or \phi if the matching is possible where \phi is a substitution function mapping the variables of the crosscut to their corresponding ones in the join point that matches. 

An aspect is defined by a recursive definied by a recursive definition, a sequence and a choice which make the aspect language more expressive than that defined by AspectJ. Some keywords also are introduced as: skip, never, always.

Aspect Composition is defined using the parallel operator II and the interaction between aspects are considered when two ore more aspects crosscuts matches the same join point. 

The weaving is described using two functions : sel that takes the an aspect and returns the rule to apply at the current join point. and a next function that takes an aspect and returns the aspect to be applied at the next join point.

In order to detect intercation conflict two kind of independance is defined to be checked when a composition operator is occured:

1. Strong Independence: Two crosscuts C and C' are strongly independent iff C^C'= fail. Two aspects A and A' are strongly independent iff A II A' can be expressed as a single aspect without II or >< operators. To do so, some simplification rules are defined. 

2. Independent w.r.t a Program : Two aspects A and A' are w.r.t a program independent iff Iw(A II A', I>) can be expressed as a single aspect without II or >< operators.  Where Iw is a function defined based on the sequence of join points occuring for a program P.

The previous crosscuts were syntactic based crosscuts. The presented model also supports semantic based crosscuts that can be defined using terms or constructors.

The proposed solutions to resolve conflict interaction are simply proposed by introduising some special parallel operators indicating to the analyzer how the conflict can be resolved. The analyzer uses these operators and checks for possible other conflicts and so forth until no conflict is occured. Also introducing a scopes for aspects is used to control the visibility of the aspects. preventing cycles in scope declarations ensures that non-terminating weaving never occurs. 

A comparison between the proposed model and the implement model AspectJ is made for all new presented concept supported by the model in the paper.},
	Address = {London, UK},
	Author = {R{\'e}mi Douence and Pascal Fradet and Mario S{\"u}dhot},
	Booktitle = {GPCE'06: Proceedings of the 1st ACM SIGPLAN/SIGSOFT conference on Generative programming and component engineering},
	Date-Added = {2008-10-28 17:53:07 +0100},
	Date-Modified = {2008-11-02 00:03:29 +0100},
	Keywords = {Detection, Reuse, Inetraction, Aspects, Conflicts, Analysis},
	Pages = {173-188},
	Publisher = {Springer-Verlag},
	Title = {A Framework for the Detection and the Resolution of Aspect Interaction},
	Year = {2002},
	Bdsk-File-1 = { }}

@techreport{CASB,
	Abstract = {In this technical report, a formal semantics is introduced to describe the formal meanning of the aspect oriented mechanisms.  The semantics is described in term of a binary relation ->b on configuration. A configuration is described as a pair (C, \segma) where C is a sequence of basic instruction describing the program and \segma  describes the program states.

The semantics is used in the present technical report for a simple arithmitic language and for a small imperative language. According to the language structure functions are added to the program configuration.

For the case of aspect weaving semantic description  a function \phi is added such that : \phi : instruction --> (\state --> instructions) x {before, after, around}, so for the before advice the semantic is:  \phi(i) =(\pi, before) => (i: C, \segma) -> (test \pi : {\^\i} : C, \segma) where test \pi is the application od \pi to the  state \segma in order to insert the advice code.

For the around advice a peoceed stack  P is added to the semantic language which involves the use of pushp and popp functions to manage the stack. That way the semantic of the aroud advice is defined as: 

              \phi(i) = (\pi, around) => (i : C, \segma, P) -> (test \pi : popp : C: \segma : {\^\i} : P) where popp is defined as: (popp : C, \segma, i : P) -> (C, \segma, P) and the proceed is defined as:  (procced : C, \segma, i: P) -> (i : pushp i : C, \segma, P)

in the case of weaving several aspects at the same joinpoint two cases are considered:
1. aspects of the same kind: before* is defined as: \phi(i) = ((\pi1, ..., \pin), before) => (i : C, \segma) -> (test \pi1 : ... : test \pin : {\^\i} : C, \segma)
2. aspects of different kinds: the function \phi has changed to return a set of pairs of (pi, t), the before and after advices are transformed into around advices using a function \gama and the around* aspect is defined as:

          \phi (i) = ((\pi1, t1), ...(\pin, tn))   \gama((\pi1, t1)...(\pin, tn)) = ((\pi1', around) ... (\pin')) => (i : C, \segma, P) -> (test \pi1' : popp n : C, \segma, test \pi1' : ... : test \pin' : {\^\i} : P)

For the specification of pointcuts a function match : Px Instruction -> bool is used to whether a pointcut P matches an instruction i. So the function \phi is redefined again to be:

   \phi(i) =   (\delta(\pi), type)  < matche(P, i) >  \eps where \delta(P) = i --- asubstitution ----which used to pass the pointcut information form the instruction to the advice.   
 
A language for pointcuts is defined and the match function is defined for that language to support the different form of pointcuts. The smae strategy has been applied to define the semantic of the cflow pointcut.

Exception handling and aspect assocaition semantice are also described and the statful aspect concept is introduced with its semantic with the assertion that a stateful aspect inserts an advice when it matches a sequence of instructions.
 },
	Author = {Simplice Djoko Djoko and R{\'e}mi Douence and Pascal Fradet and Didier Le Botlan},
	Date-Added = {2008-10-28 16:34:05 +0100},
	Date-Modified = {2008-10-29 14:29:17 +0100},
	Institution = {AOSD-Europe, INRIA},
	Keywords = {Semantics, Aspect-Oriented Programming},
	Month = {February},
	Number = {41},
	Title = {CASB: Common Aspect Semantics Base},
	Type = {Deliverable},
	Year = {2006},
	Bdsk-File-1 = { }}

@inproceedings{perserAspects,
	Abstract = {In this paper, aspects are classified into categories, each category has a set of properties that preserves. That way, when an aspect is used, it is enough to know the category that it belongs to to know the properties that it preserves when it weaved to any base program. The defined categories are :

1. Observers : set of aspects do not change the base program state and cotrol flow, their advices only change local variable states.
2. Aborters: are observes with the ability to stop the excecution of the base program.
3. Confiners: can modify the state and the control flow of the base program with preserving the reachability of the states of the base program.
4. Weak inturders: may change the state and the control flow of the base class and produces unreachable states with their advices but it returns to reachable states when it returns to the base program.

The previous four categories are related to each other by the inclusion relation from observers to weak intruders in the same order as presented. So that, the properties preserved by each category is subset of properties of the category that it includes.

The base and the aspect programs are described using CASB (i.e. Common Aspect Semantics Base for AOP, and the preserved properties are decscribed using LTL (i.e. Linear Temporal Logic) for deterministic programs and using CTL (i.e. Branching Temporal Logic) for non-detreministic programs. In the later cas, two other cathegoris of aspects are introduced:

5. Selectors: do not modify the state of the base program but may modify the control flow of it by selecting a suset of possible traces among all the possible ones in the base program.
6. Regulators: are selectors with the ability to abort the execution of the base program.

CASB:
---------
CABS semantics is based on a beniray relation ->b that describes a reduction on a configuration (C, \segma) where C is the program code instruction sequence whic is defined recursivelly as: C::= i: C I . ans \segma is the state of the program C which is abstract. A single reduction step of the base language semantics is described as:
             (i: C, \segma) ->b (C', \segma')   where i is the current instruction.
For a woven configuration: \segma = \segmab U \segmaa U \segma\phi where: \segmab  is the state of the base program, \segmaa is the state of the aspect program and \segma\phi is a function that decides whether the current instruction should be woven and transforms the configuration accordingly.
},
	Address = {New York, NY, USA},
	Author = {Simplice Djoko Djoko and R{\'e}mi Douence and Pascal Fradet},
	Booktitle = {PEPM '08: Proceedings of the 2008 ACM SIGPLAN symposium on Partial evaluation and semantics-based program manipulation},
	Date-Added = {2008-10-21 17:41:32 +0200},
	Date-Modified = {2008-10-26 18:16:55 +0100},
	Keywords = {Aspect Weaving, Semantics, Tomporal properties, Proofs},
	Pages = {135-145},
	Publisher = {ACM},
	Title = {Aspects Preserving Properties},
	Year = {2008},
	Bdsk-File-1 = { }}

@inproceedings{conAspect,
	Abstract = {Event Based AOP (EAOP) is defined in the paper, an aspect in EAOP is described as : B::= us.(I I i=1,..,n  ei; Bi) I s' where : e : is an event. This general syntax can be transformed automatically to the Finite Sequential Process (FSP) in order to use Labeled Transition System Annalyzer (LTSA) to verify properities of the aspect. Applying an aspect to base program in EAOP involoves introducing some sunchronization events describing the begin and the end of the events captured by pointcuts enclosing the adice execution event. That was for sequential process. For concurent process, a base program is shown as parallel process, for that reason the parallism operator II and hiding event /{event} are introduced in the model.  
 
In EAOP two some composition operators are introduced for composing aspects, the others mentioned two of them in details. A renaming process should be done, so that the aspects do not synchronize anymore together or with the base program:
 1. Sequential Functional Composition (Fun): Where two advices want to be executed at the same joinpoint. Fun exectutes the advices of its first argument then executes the advice of its secend argument.   
 2. Parallel conjunctive composition (ParAnd): Where two advices want to be executed at the same joinpoint, ParAnd executes their before actions in parrallel and they meet each other at the skip or proceed actions.

As an implementation model, a prototype for Java is implemented. In that tool, in order to execute coherently a shared action, two synchronized barrier are used. one to block the first process wants to execute the shared action until the other will be ready to execute that action. The second barrier called exit bocks the first one proceeded the action until all the other proceeded it. A monitor is associayed to the program, that monitor is responsible of counting the number of processes (i.e. LTSs) interessted to execute a shared action. 
},
	Address = {New York, NY, USA},
	Author = {R{\'e}mi Douence and Didier Le Botlan and Jacques Noy{\'e} and Mario S{\"u}dhot},
	Booktitle = {GPCE'06: Proceedings of the 5th international conference on Generative programming and component engineering},
	Date-Added = {2008-10-21 12:34:10 +0200},
	Date-Modified = {2008-10-23 00:41:30 +0200},
	Keywords = {Aspect-Oriented Programming, concurrency, formal verification, implementation, Java},
	Pages = {79-88},
	Publisher = {ACM},
	Rating = {0},
	Read = {Yes},
	Title = {Concurent Aspects},
	Year = {2006},
	Bdsk-File-1 = { }}

@conference{ProtKmelia,
	Abstract = {In Kmelia two vertical structuring mechanisms are availabe:
    1.  << >> structuring operator (state annotation) : used to denote on optional service that can be called when the composite service reaches a given state or transition. 
    2. II II structuring operator (transition annotation): used to denote mandatory services that should be called by a service or transtion.

Both operators have an operational semantics defined in terms of updating the formal orignal definition of services. 

Kmelia also provides protocols to control services calls. These protocols are defined using the vertical structuring operators. It also provides free services that can be called freely. A protocal in Kmelia is defined as specific service with restrictions of label of transitions which should be either local vriables modification or annotations (i.e. II II operator).

Integration protocols to Kmelia imposes adding some properties for testing inconsisties between components. This inconsisty problem can be detected by testing the pre and postconditions of the services in the chains. But it is still a challenge when the local variables are omitted for the proof of the property that should be satisfied by the component to be consistent.},
	Author = {Pascal Andr{\'e} and Gille Ardourel and Christian Attiogb{\'e}},
	Booktitle = {Software Composition},
	Date-Added = {2008-10-20 14:37:02 +0200},
	Date-Modified = {2008-10-22 15:36:34 +0200},
	Keywords = {Components, Services, Composition, Protocols, Property Analysis },
	Month = {December},
	Pages = {2-17},
	Publisher = {Springer Berlin / Heidelberg},
	Series = {Lecture Notes in Computer Science},
	Title = {Defining Component Protocols with Service Composition: Illustration with the Kmelia Model},
	Volume = {4829},
	Year = {2007},
	Bdsk-File-1 = { }}

@conference{FKmelia,
	Abstract = {In Kmelia a component is formalized as 8-tuple <W, Init, A, N, I, Ds, v, Cs>  where:
     W is the state space which is formalized as 4-tuple <T, V, Vt, Inv> where:
                  T: is a set of types.
                   V: is a set of variable names.
                   Vt is a relation T<---> V
                   Inv: is a set of invariants among the variables
     Init : is the inialization of the Vt variables
     A: is a finite set of elementary actions
     N: is a set of service names
      I: is the union of Ir and Ip which represent the required services names and the provided services names, respectivelly.
     Ds: is the union of Dsr and Dsp which represent the sets of the required and the provided services descriptions, respectivelly. where Ds is defined as a tuple <Is, Bs> where :
                    Is: is the interface of the service which is in turn defined as 5-tuple <&, P, Q, Vs, Ss> where:
                                  &: is the signature of the service.
                                  P, Q: the pre and postcondition of the service s
                                  Vs: is the local declaration for the service s
                                  Ss: is the dependency of s, which is defined as 4-tuple <subs, cals, reqs, ints> where:
                                                      subs: the set of subprovided services in the context of s
                                                      cals: the set of required services from the caller
                                                      reqs: the set of required services from other components
                                                      ints: the set of internal services called by s.
                    Bs: is the behavior of s which is defined as 6-tuple <St, S0, SF, {\S}, L, &> where:
                                 St: the set of states.
                                 S0, SF: are the initial and the set of final states of s, respectivelly.
                                  {\S} : is the transition function defined as: StxL ---------> St
                                  L: a set of transition labels
                                  &: is partial function that annotates states defined as: St ---------> subs

An assembly in Kmelia is definedas a triple <C, links, subs>  where:
      C: is a set of components
      links: is the set of links between the services of C
      subs: is a relation of links to sublinks

A component composition is defined as a well-formed assembly which is encapsulated within a component.     },
	Author = {Cristian Attiogb{\'e} and Pascal Andr{\'e} and Gille Ardourel},
	Booktitle = {Software Composition},
	Date-Added = {2008-10-20 13:29:33 +0200},
	Date-Modified = {2008-10-22 15:30:03 +0200},
	Keywords = {Components, Services, Behavioral Interface Description, Composability, Behavioral Verification},
	Month = {August},
	Pages = {18-33},
	Publisher = {Springer Berlin / Heidelberg},
	Series = {Lecture Notes in Computer Science},
	Title = {Checking Component Composability},
	Volume = {4089},
	Year = {2006},
	Bdsk-File-1 = { }}

@article{HBIDL,
	Abstract = {The Interface Description Language (IDL) has been considered as a common language to describe components interoperability for component models. IDL describe interfaces by specifying their services signatures. However, ensuring components inetroperability needs more information about services such as their dynamic behaviors. Behavioral IDL (BIDL) has been developped for such reason. BIDL describes services by specifying their signatures and the order of their invocations with their dynamic behavior using protocols. Unfortunatly, BIDL considers services as atomic operations and services calls as messages sending which in fact not true. Services can be either atomic operations or more complex operations such as requiring multiple interactions and it can call other services. Hierarchical BIDL (HBIDL) consider services as entities that can be defined by their signatures and behaviors, can be composed with other services and has interface dependencies .

HBIDL has many advantages:
1. provides detailed documntations of complex interaction services to help the user to understand the execution process and to choose the right components to satisfy its requirements. 
2. supports the compatibility levels which makes its components compatible with other components specified at low level (i.e. IDL or BIDL).
3. serves as an intermediate between CBSE and SOSE.  

The adaptation process for Kmelia consists of making signature, interface matching between component services or messages then making behavioral compatibility by exporting the internal Kmelia specification of services to MEC or LOTOS and reusing their model checking tools to provide the result. When an adaptation problem occures, the compatibility level of the  problem should be indicated, the king of the adaptation problem should be identified and an adaptator should be implicitly generated to resolve the problem, finaly an evaluation of the cost in in terms of Kmelia structuring operators should be estabilished.

Many kinds of adaptation problems may appear:

1. Parameters vs Messages mismatch: a caller sends a sequence of messges one for each parameter to the reciever while the reciver has a services with all the parameters in the same signature. This problem can be avoided in Kmelia by detecting the sequence of messages and an adaptor component is automatically generated to recieve the parameters of the caller, gather them and redirect the message to the reciever using a special operator. This problem can be also expressed differently: the caller and the reciever have not the same granularity of the parameters, in this case a composition or a decomposition of data should be made to avoid the problem.

2. Hierarchichal mismatch :  a caller expects a connection to a simple service and it is connected to a  hierarchichal service. This adaptation problem can be detected by COSTO tools when a deadlock occurs. This adaptation problem can be resolved by generating an adaptor that delays the communcation just before the deadlock and communicated with the subservices then redirect the result to the caller.  },
	Author = {Pascal Andr{\'e} and Gille Ardourel and Christian Attiogb{\'e}},
	Date-Added = {2008-10-19 14:33:50 +0200},
	Date-Modified = {2008-10-22 15:39:51 +0200},
	Journal = {Electronic Notes in Theoretical Computer Science},
	Keywords = {Adaptation, Components, Services, Behavioral Interface Description, Hierarchisation},
	Pages = {5-20},
	Publisher = {Elsevier Science Publishers B. V.},
	Title = {Adaptation for Hierarchical Components and Services},
	Volume = {189},
	Year = {2007},
	Bdsk-File-1 = { }}

@conference{COSTO,
	Abstract = {COSTO is a short description of  COmponent Study TOolbox. COSTO is a toolbox that supports the design and analysis of Kmelia's abstract component model. COSTO has been implemented as an eclipse plugin with the integration of several wizards and views. 

COSTO toolbox consists of 4 main modules that interact with each other:
1. Verification module: Defines the verification processes and architectural properties (e.g. correct composition and assembly)
2. LOTOS module: translates Kmelia specification to LOTOS specification to be checked by CADP toolbox, This later is made by translation the internal representation of Kmelia specifiation previously made by Kmelia parser into LOTOS processes and compose both processes corresponding to the pair of services using the parallel operator, then the CADP with its tools check for freeliveness and consistent of the composition operator.
3. MEC module: transforms the Kmelia specification to MEC specification to be checked by the MEC model checker for testing deadlock freeness. 
4. COSTO core module: used to analyse and parse Kmelia specification. This Later is used by all the other modules.
5. Export module: Used for generation documentation about the Kmelia specifications and grahical views of the their behaviors.

The idea behind COSTO verification of compatibility resides in the behavior compatibility checking of eLTSs of diferent services. In order to  takle state explosion, COSTO doesn't check global eLTSs of the whole system, it is just select one of a given interface service and check its compatibility only with its involved services. This step is repeated for each linked pair services of the component assembly.   },
	Address = {Zurich, Switzerland},
	Author = {Pascal Andr{\'e} and Gille Ardourel and Christian Attiogb{\'e}},
	Booktitle = {ProVeCS 2007 - Satellite Event of TOOLS Europe},
	Date-Added = {2008-10-18 11:32:24 +0200},
	Date-Modified = {2008-10-29 15:38:39 +0100},
	Keywords = {Property Verification Toolbox, Components, Services, Model Checking},
	Pages = {to appear},
	Publisher = {ETH Research Report},
	Title = {A Formal Analysis Toolbox for the Kmelia Component Model},
	Year = {2007},
	Bdsk-File-1 = { }}

@conference{Kmelia,
	Abstract = {Kmelia is a hierarchical component model, a component system in Kmelia is: a set of components, a set of connectors and a set of configurations to provide the complete system. Kmelia follow the monadic semantic which doesn't allow links between more than two services. Furthermore Kmelia assocites behaviors to services and not to components.

The Kmelia model aims to enhence the component systems constraints expression and refinements. According to the authors Kmelia is a formal model for components architectures and refinements.

In Kmelia,  connectors are not simple links or operations but they are first class entities.

Kmelia provides a hierachisation of interface services, in which each servise has a dependance, this later is defined as a 4-uplets of:
1. subprovided services: are services provided the component where the service is defined
2. calrequired services: services required by the component, in which the service is defined, from a component connected to the global service.
3. extrequired services: services required from extrenl components, i.e. not connected to the global service.
4. interrequired services: services defined but not provided (i.e. encapsulated) in the same component in which the service is defined.

A component composition in Kmeila is defined as encapsulation of components assembly (componants with the links between them) that composition may include a whole configuration. In the composed component, there is no need to link all the required services and all the provided ones, only partial configuration can be used, furthermore, a renaming is possible to simplify the result architecture and for more flexiblity in using it later.

Kmelia provides four specification levels of services: signature, assertions, enriched signature and dynamic behavior specifications.
1. signature: specifies the name, the parameters and the returned type of the service.
2. assertion: pre and postcondions of the service execution
3. enriched signature: local variables and the dependance of the service
4. dynamic behavior: an  eLTS describing initial and final states, labels and transirionrelation

Kmelia has the ability for analysing the possiblity of composition. The composition has been resumed to statique and dynamique introperability.
Statique introperability analyses the interface specification in Kmelia by checking the signatures, assertions and find possible links could be realized between services.
Dynamique intropirability detects dedlock problems in the interaction between services which are considered as processes. 

Two tools MEC and LOTOS:CADP are used to achieve the inroperability checking. However, MEC doesn't support types and gardes which LOTOS does. For the assertion checking, it is'nt yet developped.

COSTO is a protype in Java that implements the idea of the paper without assertions check. 


},
	Author = {Pascal Andr{\'e} and Gille Ardourel and Christian Attiogb{\'e}},
	Booktitle = {1{\`e}re Conf{\'e}rence Francophone sur les architectures Logicielles},
	Date-Added = {2008-10-14 10:16:20 +0200},
	Date-Modified = {2008-10-22 19:57:03 +0200},
	Keywords = {Software Architecture, Components, Services, Hierarchisation, Formal Methods},
	Pages = {101-118},
	Publisher = {Herm{\`e}s Sciences Publications - Lavoisier},
	Title = {Sp{\'e}cification d'architectures logicielles en Kmelia: hi{\'e}rarchie de connexion et composition},
	Year = {2006},
	Bdsk-File-1 = { }}

@article{Fractal,
	Abstract = {Fractal Component Model has the following main features:

1. Hierarchical 
2. Supports sharing compononts
3. Reflective model

Julia is the implementation model for Fractal in Java

The problem behind the development of the Fractal model is the lack of extension and the adaptaion of the existing component models (according to the auther). The solution of that problems proposed by Fractal is the introduction of the notion of component endowed  with an open set of control capabilities sush as: component and interface introspection intercession.

A component in Fractal is a run-time encapsulated entity which has a distinct name and supports one or more interfaces. A component in Fractal has two main parts:

1. Membrane that supports server and client interfaces which is composed of controllers
2. Content which is the set of subcomponents.

There are three kind of components : basic components (i.e. a component without any control interfaces), primitive component (i.e. a component that it has not a content but it has at least one control interface) and a composite component (i.e. a component with content and control interfaces). 

Fractal supports both primitive and composite binding:
1. primitive binding is a direct connection between a server (i.e. provided)  and a client (i.e. required) interfaces.
2. composite binding is indirect connection between interfaces which forms a path of primitive bindings.

Fractal provides at the abstract level some predifined controllers to expose the elements of its structure, such us: Attribute controller, Binding Controller, Content Controller and life-cycle controller.

Fractal provide a type system for the interfaces of its components. An interface type describes the operations supported by the given interface, its contingency (i.e. the availability of a given operation of the interface while the component is running) and its cardinality (i.e. the number of interfaces of type T for a given component). The typing system has the subtyping functionnality to support components substitution.

Fractal model provides the concept of factory components (i.e. components able to create other components) to support components creation. It supports two kinds of such components: generic factory components and standards components interfaces (e.g. template). 

In order to create a component architecture using Fractal model you have to follow the next steps:
1. create the enclosing factory component with its interface types by getting a reference to the bootstrap component which is necessary to initialise the achitecture. },
	Author = {Eric Bruneton and Thierry Coupaye and Matthieu Leclercq and Vivien Qu{\'e}ma and Jean-Bernard Stefani},
	Date-Added = {2008-10-11 18:07:31 +0200},
	Date-Modified = {2008-10-23 13:42:19 +0200},
	Journal = {Software-Practice and Experience},
	Keywords = {component-based programming, reflective component model, aspects and components, Java components},
	Month = {August},
	Number = {11-12},
	Pages = {1257-1284},
	Title = {The Fractal Component Model and its Support in Java},
	Volume = {36},
	Year = {2006},
	Bdsk-File-1 = { },
	Bdsk-File-2 = { }}

@comment{BibDesk Static Groups{
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<array>
	<dict>
		<key>group name</key>
		<string>CBSE Models</string>
		<key>keys</key>
		<string>Kmelia,Fractal</string>
	</dict>
</array>
</plist>
}}
