当前位置:文档之家› Mapping features to models A template approach based on superimposed variants

Mapping features to models A template approach based on superimposed variants

Mapping features to models A template approach based on superimposed variants
Mapping features to models A template approach based on superimposed variants

Mapping Features to Models:A Template

Approach Based on Superimposed Variants

Krzysztof Czarnecki and Micha l Antkiewicz

University of Waterloo,Canada

Abstract.Although a feature model can represent commonalities and

variabilities in a very concise taxonomic form,features in a feature model

are merely symbols.Mapping features to other models,such as behavioral

or data speci?cations,gives them semantics.In this paper,we propose a

general template-based approach for mapping feature models to concise

representations of variability in di?erent kinds of other models.We show

how the approach can be applied to UML2.0activity and class models

and describe a prototype implementation.

1Introduction

Feature modeling is an important method and notation to elicit and represent common and variable features of the systems in a product line.It can be used at any level of abstraction,including requirements,architecture and design,compo-nents,and platforms;for any kind of artifacts,such as code,models,documen-tation;and in all stages of product-line engineering.At an early stage,feature modeling enables product-line scoping,i.e.,deciding which features should be supported by a product line and which should not.In design,the points and ranges of variation captured in feature models need to be mapped to a common product-line architecture.Furthermore,feature models allow us to scope and de-rive domain-speci?c languages,which are used to specify product-line members in generative software development[1–3].Finally,feature models are also useful in product development as a basis for estimating development cost and e?ort, and automated or manual product derivation.

Although a feature model can represent commonalities and variabilities in a very concise taxonomic form,features in a feature model are merely symbols. Mapping features to other models,such as behavioral or data speci?cations, gives them semantics.In this paper,we propose a general approach for map-ping feature models to concise representations of variability in di?erent kinds of other models.In contrast to variability approaches in which separate model frag-ments corresponding to di?erent features are composed,our approach presents the modeler with a model representing a superimposition of all variants whose elements are related to the corresponding features through annotations.We ar-gue that this approach is particularly desirable at the requirements level,as it directly shows the impact of selecting a given feature on the resulting model. The proposed approach is general;it works for any model whose metamodel is

2

expressed in the Meta-Object Facility(MOF)[4]or a comparable modeling for-malism,and it can be easily incorporated into an existing model editor.We give the details of our approach for mapping feature models to UML2.0activity dia-grams and indicate how it can be applied to other kinds of models.We describe a prototype implementation of our approach.The sample models presented in this paper are taken from a large model of an e-commerce platform,which we used to test our approach.

The remainder of the paper is organized as follows.Section2reviews back-ground concepts and related work on feature modeling.Next we describe the idea in sections3and4.Section5presents the details of template instantiation algorithm.We describe the implementation of the prototype in section6.We discuss related work in section7and conclude the paper in section8.

2Background:Feature Modeling

Feature modeling was originally proposed as part of the Feature-Oriented Do-main Analysis(FODA)method[5],and since then,it has been applied in a range of business and technical domains(see[6]for list of applications with refer-ences).In this work,we use cardinality-based feature modeling[7],which extends the original feature modeling from FODA with feature and group cardinalities, feature attributes,feature diagram references,and user-de?ned annotations.

A feature is a system property that is relevant to some stakeholder and is used to capture commonalities or discriminate among systems in a family[1]. Features are organized in feature diagrams.A feature diagram is a tree with the root representing a concept(e.g.,a software system)and its descendant nodes being features.A feature model consists of one or more feature diagrams plus additional information such as feature descriptions,global constraints,binding times,priorities,stakeholders,etc.

Figure1(a)presents a small excerpt from a feature model describing a fam-ily of online business-to-consumer(B2C)solutions;the entire model has over 350features.The model contains one feature diagram,with eCommerce as its root feature.The root feature has two solitary subfeatures:Storefront and BusinessManagement.The symbol indicates that Storefront has a feature cardinality of[1..1].Feature cardinality is an interval denoting how often a fea-ture with its subfeatures can be cloned as a child of its parent when specifying a concrete system.The cardinality of[1..1]indicates that a feature must ex-ist at least and at most once.On the other hand,the symbol indicates that

WishLists is an optional feature with cardinality[0..1].Available checkout types Registered and Guest,are members of a feature group.The group symbol

indicates group cardinality 1–k ,where k is the group size.Thus available checkout types can be any non-empty subset of the two checkout types.Grouped features are indicated by the symbol.

One can specify additional constraints such as requires or excludes.For exam-ple,the feature PersistentBetweenSessions requires the system to implement Registration because a wish list is stored in a customer’s account.Also,check-

3

(a)Online B2C Feature Model(b)Feature con?guration

Fig.1.Sample online B2C feature model and its feature con?guration

out type Registered requires feature Registration to be selected.In general, additional constraints in cardinality-based feature models require tree-oriented navigation and query facilities,and may involve logic,arithmetic,string,and set operators on feature attributes and feature sets.Such constraints can be adequately expressed using XPath2.0[8].

Semantically,a feature model describes a set of all possible valid con?gura-tions[7].Figure1(b)presents a sample con?guration of the online B2C feature model.A con?guration speci?es a concrete system.In this example,checkout for registered customers is the only available checkout type,the catalog is sub-divided into categories,a product can be classi?ed in multiple categories,the catalog contains only electronic goods,etc.

4

3Basic Idea:Superimposed Variants

An overview of our approach is shown in Figure 2.A model family is represented by a feature model and a model template .The feature model de?nes a hierarchy of features together with the constraints on their possible con?gurations.The model template contains the union of the model elements in all valid template instances .The set of the valid template instances corresponds to the extent of the model family.The model template is itself a model expressed in the same target notation as the template instances.For example if we want to represent a family of UML activity models,both the model template and the template instances will be expressed using the UML activity modeling notation.The ele-ments of a model template may be annotated using presence conditions (PCs)and meta-expressions (MEs).These annotations are de?ned in terms of features and feature attributes from the feature model,and can be evaluated with respect to a feature con?guration.A PC attached to a model element indicates whether the element should be present in or removed from a template instance.MEs are used to compute attributes of model elements,such as the name of an element or the return type of an operation.Manual configuration process

Feature model Feature configuration

Refers to features

through annotations Automatic template instantiation

conditions and meta?expressions

? Evaluation of presence

? Element removal

? Post?processing Template instance

Model template

expressed in target notation and annotated

with presence conditions and meta?expressions

Fig.2.Overview of the approach

An instance of a model family can be speci?ed by creating a feature con?gu-ration based on the feature model.Based on the feature con?guration,the model template is instantiated automatically.The instantiation process is a model-to-model transformation with both the input and output expressed in the target notation.It involves evaluating the PCs and MEs with respect to the feature con-?guration,removing model elements whose PCs evaluate to false and,possibly,additional processing such as simpli?cation (Section 5).

A particularly useful form of PCs are Boolean formulas over the set of vari-ables,where each variable corresponds to a feature from the feature model.Given

5 a feature con?guration,the value of a given Boolean variable is true if and only if the corresponding feature is included in the feature con?guration.

As an example,consider the UML activity diagram in Figure3(a),which models the top-level activity of a storefront.This diagram is a template since elements relevant to features WishLists,SendWishList and Registration have been annotated with their PCs.The annotations are rendered using a coloring scheme in which each di?erent PC is assigned a di?erent color.1In this simple example,each PC consists of a single variable corresponding to a single feature. Figure3(b)shows a template instance created based on the feature con?guration from Figure1(b).PCs corresponding to feature SendWishList,which is not included in the con?guration,evaluated to false and the annotated elements were removed from the template.

(a)Storefront template(b)Storefront instance

Fig.3.Sample template activity diagram and its instance It is important to note that PCs are interpreted locally with respect to con-tainment hierarchies de?ned in the metamodel of the target notation.In other words,a PC on an element controls the presence of that element only with re-spect to its container;if the container is removed,all contained elements are also removed,regardless of their PCs.For that reason,we did not have to anno-tate the guards on?ows in Figure3(a)because they are contained in the?ows according to the UML metamodel.

More complex PCs can be expressed using XPath[9].Such conditions can access feature attributes,count the number of feature clones in a con?guration,

6

and use other XPath operations,as long as the XPath expression evaluates to a Boolean value.If necessary,XPath can be easily extended with user-de?ned functions.

MEs may be used to compute attributes of basic types,as well as references to model elements.In this paper,we only consider computing references to al-ready existing elements.MEs can be expressed using XPath.As an example,consider the activity diagram fragment in Figure 4.The type of the input pin of action DisplayProducts is set to b2cSoln::Category or b2cSoln::Catalog depending on the presence of the Categories feature in the feature con?gura-tion.

12Fig.4.Example of a type meta-expression

Categories & !MultipleClassification MultipleClassification | !Categories MultipleClassification Presence conditions:

AssociatedAssets

PhysicalGoods

true

Categories

MultiLevel 1324657Fig.5.Example of annotated class diagram

Figure 5shows an annotated class diagram.Class Category is present in a template instance if the feature Categories is selected.Feature MultiLevel im-plies a containment hierarchy for Category .MultipleClassification implies that Product s can be classi?ed under multiple categories.AssociatedAssets

7 implies the class Asset,which can be used for storing documents such as techni-cal speci?cations and manuals and other media.Finally,PhysicalGoods implies the attribute weight in Product.

The realization of our approach for a given target notation involves the fol-lowing steps:

1.decide on the form of PCs and MEs,for example Boolean formulas and/or

XPath expressions;

2.decide on implicit PCs.Model elements that are not explicitly annotated by

the user will have implicit PCs;implicit PCs will be explained shortly;

3.decide on the annotation mechanism and rendering options for the annota-

tions,e.g.,if the target notation is UML,the annotations can be realized as stereotypes;rendering options include labels,icons,and/or coloring;

4.decide on additional processing.

Steps2–4depend on the target notation.In the following sections,we will demon-strate details for UML activity diagrams as a target notation.2

4Implicit Presence Conditions

When an element has not been explicitly assigned a PC by the user,an implicit PC(IPC)is assumed.In general,assuming a PC of true is a simple choice which is mostly adequate in practice;however,sometimes a more useful IPC for an element of a given type can be provided based on the presence conditions of other elements and the syntax and semantics of the target notation.For example,according to UML syntax,a binary association requires a classi?er at each of its ends.Thus,a reasonable choice of IPC for a binary association would be the conjunction of the PCs of both classi?ers.This way,removing any of the classi?ers will also lead to the removal of the association.IPCs reduce the necessary annotation e?ort of the user.For example,given the IPC for associations as described,the association between Product and Asset in Figure 5does not need to be annotated explicitly.

Table1shows our choice of IPCs for UML class and activity model elements. An IPC for a given element is assumed based on its type.In order to determine the IPC for a given model element,we look up the closest matching supertype in Table1and take the corresponding IPC.For example,the IPC for instances of Class and Action is true because their closest matching type in Table1 is Element.Since ActivityFinalNode and FlowFinalNode are subclasses of FinalNode according to the UML metamodel,the IPC for ActivityFinalNode and FlowFinalNode is the same as for FinalNode in Table1.

The choice of IPCs in Table1re?ects the cardinality and other integrity constraints speci?ed in the UML metamodel.For class models,the IPC for all elements except relationships is true.In the case of generalization,which is a

8

Table1.Implicit presence conditions for UML class and activity model elements

Implicit presence condition a

Model

kind

Element

Class Conjunction of the PCs of the general and specific classi?ers Dependency

true i?two or more memberEnd properties such that each has a

classi?er with PCs evaluating to true as its type

InitialNode

Disjunction of the PCs of all incoming?ows

DecisionNode and

ForkNode

true i?exactly one outgoing?ow’s PC evaluates to true and one

or more incoming?ows’PCs evaluate to true

CentralBufferNode

true i?accumulated PC of the called operation evaluates to true CallBehaviorAction

a PC stands for presence condition(both explicit or implicit).Names in typewriter font(except

true)refer to properties of the corresponding element.

binary relationship,the IPC re?ects the fact that such a relationship can exist in a template instance only if the classi?ers at both ends of the relationship are also present in the template instance.The IPCs for dependencies and associations need to handle the more general case of n-ary relationships.For activity models, the IPC for all elements except control nodes,central bu?er node,and call actions is true.Control nodes have to have at least one incoming?ow and/or at least one outgoing?ow in an instance as speci?ed in the metamodel.Central bu?er has to have at least one incoming?ow or outgoing?ow.Finally,the target of call actions has to be present.

Control nodes are not intended to be annotated with PCs explicitly since their IPCs will always be adequate.This is not true for relationships in class models because we might want to remove a relationship in a template instance even if the elements the relationship connects are not removed.

IPCs for call actions re?ect the fact that removal of the target should also force removal of all actions calling it.Accumulated PC of an element is true i?PCs of all parents of that element evaluate to true.

5Template Instantiation

A simple and general template instantiation process involves computing MEs and removing elements whose PCs are false;however,the general process can be specialized for a given notation with some additional processing steps,which allow expressing templates in that notation more compactly.We have identi?ed two categories of such additional steps:patch application and simpli?cation.A patch is a transformation that automatically?xes a problem which may result

9

from removing elements.It is de?ned for situations in which there exists a unique and intuitive solution to a problem created by element removal.

Simpli?cation involves removing elements that have become redundant after removing other elements.In the case of activity models,we found it useful to provide automatic ?ow closure as a patch and removal of redundant control nodes for simpli?cation,which will be explained later.

!InventoryTracking & !PhysicalGoods InventoryTracking & !PhysicalGoods !InventoryTracking & PhysicalGoods InventoryTracking & PhysicalGoods Presence conditions:InventoryTracking PhysicalGoods true 2

4

3

1

65

Fig.6.Model templates with two optional actions without and with automatic ?ow closure

The motivating example for automatic ?ow closure is presented in Figure 6.The two actions HandleItemAvailability and ApplyShippingCosts are optional and implement features InventoryTracking and PhysicalGoods ,respectively.The top part of the ?gure presents how the two optional actions would have to be modeled without automatic ?ow closure.The bottom part contains the same fragment expressed in a natural way thanks to the automatic ?ow closure.The latter ensures that after removing an optional action the still remaining incoming ?ow and outgoing ?ow will be closed.If desired,the closure can be prevented by the user by annotating the ?ows such that they are removed together with the action.It is easy to see that,without ?ow closure,the number of ?ows needed in a chain of optional actions grows exponentially with the number of the actions.3

The complete template instantiation algorithm can be summarized as follows:

1.Evaluation of MEs and explicit PCs.The evaluation is done while travers-ing the element containment hierarchy in the template in depth-?rst order.Children of elements whose PCs evaluate to false are not visited because they will be removed.

2.Removal analysis.Removal analysis involves computing IPCs and informa-tion required for patch application,if any.The IPCs in Table 1can be com-puted in a single additional pass after computing the explicit PCs;however,

10

a di?erent choice of IPCs could require multiple iterations.Furthermore,

given the IPCs in Table1,the necessary analysis for automatic?ow closure can be performed separately after the IPCs are computed.Again,depending on the choice of IPCs and patches,such separation may not be possible. 3.Element removal and patch application.In this step,elements whose PCs

are false are removed and patches,if any,are applied.Application of a patch depends on its type and can be performed before or after removal.

4.Simpli?cation.Simpli?cation is performed at last.

5.1Template Instantiation for Activity Diagrams

The removal analysis for activity diagrams identi?es situations where?ows in-terrupted by removed elements can be closed.The identi?cation is performed during removal analysis after all IPCs have been computed and proceeds as fol-lows.Let F be the set of elements contained in an activity whose PCs(both explicit and implicit)evaluated to false.We partition F into a set of regions R such that elements in each region are connected,but no two elements from two di?erent regions are connected.Furthermore,let A r be a set of?ows adjacent to the region r.

A region r is said to be closable i?

1.there is exactly one incoming and exactly one outgoing adjacent?ow,4i.e.,

A r={i,o}∧target(i)∈r∧source(o)∈r

2.there is a?ow path connecting target(i)and source(o)

3.types of i and o are consistent i.e.,both are control or object?ows

All closeable regions are closed before elements with PCs being false are removed.Closing a region r with A r means that o is removed and the target of i is set to the target of o.If a region is not closeable and A r is not empty,there is an annotation error because?ows from A r would become dangling after the removal of region r.An annotation error can also occur if a?ow is not within the region itself,but its ends are.

Simpli?cation for activity nodes involves removing redundant control nodes such as(1)a DecisionNode or a ForkNode having one outgoing?ow,and(2)a MergeNode or a JoinNode having one incoming?ow.More sophisticated control ?ow simpli?cation could also be applied at this point,such as merging parallel ?ows without actions between a decision and merge nodes.

As an example of template instantiation for activity models with automatic ?ow closure,consider the checkout items template in Figure7and its instance in Figure8(b).The instance implements the features selected in the feature con?g-uration from Figure1(b),where the only speci?ed checkout method is for regis-tered customers(feature Registered).Features Guest,QuickCheckoutProfile, InventoryTracking and PhysicalGoods are not selected.Note that all control

11

QuickCheckoutProfile

Presence conditions:

InventoryTracking

PhysicalGoods true

Guest

Registered

52143Fig.7.Checkout Items diagram template

nodes in the template are gray,indicating that they are not annotated and therefore IPCs are assumed.

The result of removal analysis and patch application is shown in Figure 8(a).Based on our con?guration,the instantiation algorithm removes four regions:blue (3)for QuickCheckoutProfile ,green (2)for Guest checkout,magenta (4)for InventoryTracking ,and pink (5)for PhysicalGoods .Note that they are all closeable and will be closed before removal.In the case of the blue (3)region,the adjacent ?ows are those in red (1).Also note that the decision node type?has been included in the blue region because its implicit PC evaluated to false.

The ?nal result after simpli?cation,which removed one decision node customer type?and two merge nodes,is shown in Figure 8(b).

Examples of useful patches for class models include generalization chain clo-sure and containment chain closure .They are the counterpart of automatic ?ow closure for generalization and containment relationships:given the classi?ers A ,B ,and C ,if A is connected to B and B is connected to C ,removing B while the PCs of the incoming relationship and the outgoing relationship are true will connect A to C .

6Prototype Implementation

We have built a prototype to illustrate how our approach works in practice.The prototype,fmp2rsm ,is an Eclipse plug-in which integrates our Feature Modeling Plug-In (fmp)[8]with Rational Software Modeler (RSM),a UML modeling tool from IBM.5The plug-in implements the template instantiation algorithm from

12

(a)Checkout instance after region

re-

moval

(b)Checkout instance after simpli-

?cation

Fig.8.Checkout template instance

Section5,and it also performs the automatic coloring of templates based on the PC annotations.The implementation handles all of UML;however,at this point, the convenience of additional processing is available only for activity models as described in Section5.1.

The plug-in works with four artifacts:(1)UML model template created using RSM,(2)feature model created using fmp(Figure1contains screen shots of fmp),and two variability pro?les,(3)PC pro?le for PC annotations,and(4) ME pro?le for ME annotations.

The PC pro?le o?ers two forms of PC annotations:Boolean formulas in Disjunctive Normal Form(DNF)and the more general XPath expressions.Each disjunct(i.e.,a conjunction of literals)of a PC in DNF is represented as a stereo-type,e.g.,<>for the Boolean formula f1

6Each stereotype extends Element and has read-only properties encoding the actual Boolean formula.The encoding uses fully quali?ed feature names which are available as literals of an enumeration type that is automatically generated by fmp2rsm given

a feature model.In other words,the stereotype’s name is just for documentation

and may use abbreviated feature names.

13 TypedElement.For<>,an expression has to return fully quali?ed name of either a primitive type(e.g.,UML2::String),a class(e.g.,b2cSoln::Category as in Figure4),an interface,or an enumeration.The ME pro?le could be auto-matically generated based on the metamodel of a given notation.

7Related Work

Variability mechanisms most commonly used in models are those already avail-able in the target notation,such as using a decision node in an activity model to decide between alternative?ows or representing class variants as subclasses of an abstract class.Inheritance—a classical variability mechanism in class diagrams—has also been adapted for activities[11]and statecharts[12,13].Limitations of these approaches include the lack of static con?guration,as in the case of dy-namic choice such as a decision node,the potential of combinatorial explosion for static inheritance hierarchies,and complexity increase and limited traceability in the case of design patterns.

Another class of approaches is based on annotations expressing variability. In the case of UML,such annotations are usually provided as a pro?le with stereotypes,such as<>and<>,e.g.,[14].Although our approach is also annotation-based,we provide a separate representation of vari-ability in the form of a feature model.Without the latter,there is no clear notion of features and the user has to?nd and select variable elements in the model directly.Furthermore,patching and simpli?cation,as proposed in our approach, results in simpler templates.Finally,we provide full template support by means of MEs.

Wasowski describes automatic generation of variants of behavioral models (in particular statecharts)by restrictions[15].As in our approach,the modeler creates a single model containing all variants.A variant is automatically created using a form of partial evaluation and slicing based on speci?ed restrictions.The restriction approach di?ers from our template approach in several ways.First,it involves more sophisticated analysis in which restrictions on inputs and outputs are propagated throughout the model automatically.While this may result in a signi?cantly reduced annotation e?ort,the e?ect of automatic partial evaluation and slicing may be hard to predict for the user.In a template approach,the user has full control through explicit annotations.Another di?erence is that the model to be restricted has to be semantically correct in the sense that it is ready to be executed without any processing,whereas templates only need to be syntactically well-formed.The restriction approach is adequate,particularly if there is a variant that contains all of the initial model without any restrictions; however,if this is not the case,it is likely that a template will be simpler than an unrestricted model.For example,alternative?ows can simply be attached to an activity node,while the model restriction approach would require using a decision node.Also,additional processing,such as automatic?ow closure,further reduces the complexity of a template,whereas in the model restriction approach, each optional action would need an extra decision node.Finally,the template

14

can be easily adapted to any notation.This is di?erent with the restriction approach,which is semantics-based and needs to be individually developed for each notation.

Another group of work are concern separation approaches,such as AHEAD [16],and the hyperspace approach[17]and its UML realization HyperUML[18]. These approaches allow the composition of crosscutting model fragments.In par-ticular,HyperUML uses feature models to represent the composition space of UML model fragments.Mixin-based composition of statecharts[19,20]also falls into this category,but with the particular focus on ensuring provably correct composition.Concern separation approaches focus on separation.Templates,on the other hand,work best if the user wants to see the model fragment correspond-ing to a feature embedded in the context of the entire model.For example,sepa-rating the blue(3)region corresponding to the feature QuickCheckoutProfile in Figure8as a component does not seem to be interesting.This is because the fragment is not reusable and can be best understood in the context where it is applied.Separation approaches are of particular interest when features should be realized as components that can be composed in many ways,which is the case in mature and highly?exible architectures.They are also preferred for rep-resenting crosscutting concerns that can be meaningfully stated in separation, such as logging or security.For example,the fact that the checkout activity re-quires authorization can be expressed as a security annotation(a kind of join point),leaving the insertion of call actions to the approprite authorization and authentication activities to an aspect weaver.

A few modeling tools on the market support model templates in some form, but usually in an ad hoc manner.For example,templates in Rational XDE are modeled as parameterized collaborations,even though the template can contain meta-code creating arbitrary models,i.e.,the template instance is not a collabo-ration.Obviously,variability can also be realized by direct model manipulation, such as using composition directives[21]or XMI manipulation[22].

Finally,feature models have been previously used together with textual tem-plates as the structure de?nition of template input,e.g.,[23].However,the ap-plication to model templates is,to our knowledge,new.

8Concluding Remarks

The purpose of this work can be seen from di?erent perspectives:(1)giving semantics to features in feature models by mapping them to other models and (2)using feature models to provide a concise representation of variability con-tained in other models.Expressing PCs and MEs in terms of features provides traceability between features and their realization in models.

Although we think our approach is particularly useful at the requirements level,it can be applied for models at any level,e.g.,architecture and implemen-tation models.

From the usability perspective,the approach is intuitive.Model templates are in the target notation,so there is no need to learn new specialized languages

15 (except for simple feature models)and existing tools can also be reused.Implicit conditions,patching,and simpli?cation minimize annotation e?ort and decrease visual complexity,which makes model templates more concise.Coloring makes it easy to see what will be contributed by selecting a given feature.Model templates can be created incrementally and simultaneously with the feature model.

During our case study we have observed that the majority of PCs are single features.However the ability to write more complex PCs allows us to avoid polluting the feature model with features related to the implementation details of the template.For example,a“glue”element usually requires a PC being a conjunction of features.If a PC could only be simple features,an additional feature corresponding to the“glue”element would need to be introduced.

A possible concern is that annotation is not always simple and may require few iterations;however,further tool support can be o?ered,e.g.,for?ltering model template parts relevant to certain features and subset of systems,and automatic veri?cation guaranteeing the well-formedness of all possible template instances.Those additional capabilities,as well as support for element cloning in model templates,will be covered in future work.

References

1.Czarnecki,K.,Eisenecker,U.W.:Generative Programming:Methods,Tools,and

Applications.Addison-Wesley,Boston,MA(2000)

2.Czarnecki,K.:Overview of Generative Software Development.In:Proceedings of

the European Commission and US National Science Foundation Strategic Research Workshop on Unconventional Programming Paradigms,September,15–17,2004, Mont Saint-Michel,France.(2004)http://www.swen.uwaterloo.ca/~kczarnec/ gsdoverview.pdf.

3.Batory,D.:Feature Models,Grammars,and Propositional Formulas.Technical

Report TR-05-14,University of Texas at Austin,Texas(2005)

4.Object Management Group:Meta-Object Facility.(2002)https://www.doczj.com/doc/b46085621.html,/

technology/documents/formal/mof.htm.

5.Kang,K.,Cohen,S.,Hess,J.,Nowak,W.,Peterson,S.:Feature-oriented domain

analysis(FODA)feasibility study.Technical Report CMU/SEI-90-TR-21,Software Engineering Institute,Carnegie Mellon University,Pittsburgh,PA(1990)

6.Czarnecki,K.,Helsen,S.,Eisenecker,U.:Staged con?guration through specializa-

tion and multi-level con?guration of feature models.Software Process Improvement and Practice10(2005)143–169http://swen.uwaterloo.ca/~kczarnec/spip05b.

pdf.

7.Czarnecki,K.,Helsen,S.,Eisenecker,U.:Formalizing cardinality-based feature

models and their specialization.Software Process Improvement and Practice10 (2005)7–29

8.Antkiewicz,M.,Czarnecki,K.:FeaturePlugin:Feature modeling plug-in for

Eclipse.In:OOPSLA’04Eclipse Technology eXchange(ETX)Workshop.

(2004)Paper available from http://www.swen.uwaterloo.ca/~kczarnec/etx04.

pdf.Software available from gp.uwaterloo.ca/fmp.

9.World Wide Web Consortium:XML Path Language(XPath)2.0.(2005)http:

//https://www.doczj.com/doc/b46085621.html,/TR/xpath20/.

16

10.Object Management Group:Uni?ed Modeling Language2.0.(2004)http://www.

https://www.doczj.com/doc/b46085621.html,/cgi-bin/apps/doc?ptc/04-10-02.zip.

11.Schnieders,A.,Puhlmann,F.:Activity diagram inheritance.In Abramowicz,

W.,ed.:BIS2005-Business Information Systems.8th International Conference, Poznan,Poland,2005,Proceedings.(2005)

12.Lee,J.,Xue,N.L.,Kuei,T.L.:A note on state modeling through inheritance.

SIGSOFT Softw.Eng.Notes23(1998)104–110

13.A J H Simons,M P Stannett,K.E.B.,Holcombe,W.M.L.:Plug and play safely:

Rules for behavioural compatibility.In:Proc.6th IASTED Int.Conf.Software Engineering and Applications.(2002)263–268

14.Ziadi,T.,H′e lou¨e t,L.,J′e z′e quel,J.M.:Towards a uml pro?le for software product

lines.In:PFE.(2003)129–139

15.Wasowski,A.:Automatic generation of program families by model restrictions.In

Nord,R.L.,ed.:Software Product Lines:Third International Conference,SPLC 2004,Boston,MA,USA,August30-September2,2004.Proceedings.Volume3154 of Lecture Notes in Computer Science.,Heidelberg,Germany,Springer-Verlag (2004)73–89

16.Batory,D.,Sarvela,J.N.,Rauschmayer,A.:Scaling step-wise re?nement.In:

Proceedings of the25th International Conference on Software Engineering(ICSE), Portland,Oregon,Los Alamitos,CA,IEEE Computer Society(2003)187–197 17.Tarr,P.,Ossher,H.,Harrison,W.,Stanley M.Sutton,J.:N degrees of separation:

multi-dimensional separation of concerns.In:ICSE’99:Proceedings of the21st international conference on Software engineering,Los Alamitos,CA,USA,IEEE Computer Society Press(1999)107–119

18.Philippow,I.,Riebisch,M.,Boellert,K.:The hyper/UML approach for feature

based software design.In Akkawi,F.,Aldawud,O.,Booch,G.,Clarke,S.,Gray, J.,Harrison,B.,Kand′e,M.,Stein,D.,Tarr,P.,Zakaria,A.,eds.:The4th AOSD Modeling With UML Workshop.(2003)

19.McNeile,A.T.,Simons,N.:State machines as mixins.Journal of Object Technology

2(2003)85–101

20.Prehofer,C.:Plug-and-play composition of features and feature interactions with

statechart diagrams.In:FIW.(2003)43–58

21.Straw,G.,Georg,G.,Song,E.,Ghosh,S.,France,R.,Bieman,J.M.:Model com-

position directives.In Baar,T.,Strohmeier,A.,Moreira,A.,Mellor,S.J.,eds.: UML2004-The Uni?ed Modeling Language.Model Languages and Applications.

7th International Conference,Lisbon,Portugal,October11-15,2004,Proceedings.

Volume3273of LNCS.,Springer(2004)84–97

22.Jarzabek,S.,Zhang,H.:Xml-based method and tool for handling variant require-

ments in domain models.In:RE.(2001)166–173

23.Czarnecki,K.,Bednasch,T.,Unger,P.,Eisenecker,U.W.:Generative programming

for embedded software:An industrial experience report.In Batory,D.,Consel,

C.,Taha,W.,eds.:Proceedings of the ACM SIGPLAN/SIGSOFT Conference

on Generative Programming and Component Engineering(GPCE’02),Pittsburgh, October6-8,2002.Volume2487of Lecture Notes in Computer Science.,Heidelberg, Germany,Springer-Verlag(2002)156–172

猎头服务合同书

编号:_______________ 本资料为word版本,可以直接编辑和打印,感谢您的下载 猎头服务合同书 甲方:___________________ 乙方:___________________ 日期:___________________

委托方____________________以下简称甲方代理方_________人才服务部以下简称乙方甲方因业务发展需要,委托乙方搜索所需人才。 经双方友好协商,达成以下合作条款第一条 主旨本合同目的在于确定乙方代表甲方搜索候选人时双方的权利及义务。 第二条 搜索服务的基本方式1甲方需提供与所需搜索职位有关的详细资料给乙方,其中主要包括--工作环境,如公司背景、现状规模、发展状况、目前和将来的投资等;--职务名称、职位职责,个人发展前景、直属上司情况及汇报路线;--所须具备的条件包括年龄、性别、教育程度、英文程度、专业经验以及个人品性;--工作中所需要的独立性、工作氛围,流动性出差需要和上班地点等;--福利待遇包括基本工资、奖金和津贴、工作时数、生活条件以及合同保险。 2乙方工作程序--搜索可能达到该标准的候选人,对这些候选人进行初次面试筛选并确证其资料的真实性;--将候选人资料提交甲方参考,包括对其经验的评价及对其性格,能力和潜质的看法;--为双方安排面谈时间、地点,并参与其中一些条款的协商,协助聘用合同的最终签署;--协助甲方督促被录用候选人与原工作单位按正常的程序办好离职手续。 3乙方在合同签定之日起天内完成对甲方所需人才的寻访、测评及背景调查,将完整、真实的候选人资料提交甲方,并安排候选人面试。 4甲方应在收到乙方提供的候选人资料后两日内,做出是否与己有人才资料重复的判断,否则视为乙方推荐;甲方应在收到乙方提供的候选人才资料后一周内,做出是否需要复试的判断,甲方应在候选取人面试后两周内将面试意见及审核结果反馈给乙方,在复试后四周内做出是否录用的判断。 第三条 保证期1推荐的候选人被甲方录用,并最终到甲方工作,视为猎头服务成功。 2雇员在保证期三个月内无论因任何原因离职,甲方应五天内向乙方提出书面报告,乙方将免费为甲方推荐另一合适候选人到职;乙方收到甲方书面报告后二个月内没有推荐合格人选到职,乙方应退还该项服务费的_______。

猎头公司双向合作协议书

猎头公司双向合作协议书 甲方:_______________ 乙方: ________________ 甲乙双方本着共同协商、合作事宜,一致同意签订本协议: 一、甲乙双方本着资源共享,双赢合作的原则本着诚信合作的意愿进行双边合作。 二、甲方受企业托付与乙方进行双向猎头合作业务时,须提供营业执照复印件,认真填写《托付聘请需求表》对所托付的职位进行详细的描述,提供企业真实的经济性质、规模大些、进展前景等情 况,以便使乙方正确理解托付聘请岗位的要求和客观负责的向候选人介绍聘方的情况。 三、乙方在双方协商的时限内,为甲方提供符合要求的人才信息,供甲方选择;甲方对选中的推举人选进行面试,录用权在甲方 (必要时乙方可与甲方一起面试参与人才与企业的面试)。 四、甲方对乙方提供的人员进行面试后的两个星期内应明确 通知乙方是否录用。甲方在与面试人员达成一致,明确表示录用乙方推举人选之后,在推举人选上班前,支付乙方成功推举的服务费,金额为每一位人选年薪的____________ %人才上岗一个月后付清人才全部薪资的 ____ % 五、假如乙方推举给甲方的人选______ 个月内,因种种缘故离职,那么在该人选解聘后,乙方应该无偿为甲方推举合适人选,若一个月内仍然未能寻到合适人选,除非甲方要求推举,否则甲方有权要求乙方返还该人选推举费的_____________ % (甲乙双方各提取人才拥金的一半,费用也应由双方一同支付。) 六、双方要以“公开、公正、守信、诚意”为原则,共同遵 守和实施以上托付事宜。甲方必须通过乙方录用乙方提供的人员,未 经乙方同意,甲方不得在乙方不知情的情况下私下与被推举人员联系或达成有损乙方利益的约定,经发觉作违约处理。 七、凡乙方推举的人员(按约定已向乙方支付全额推举费用的人员除外),自推举之日起一年内,甲方除非得到乙方的同意,否则不得以任何理由私自录用该人。 八、乙方对违反本协议的任何行为保留一切法律行为的权利。 一经发觉,甲方在必须全额补偿乙方上述应付金额以外,乙方还有权要求甲方在发觉违约之日起两星期内,支付乙方所推举之人员 ____________ 个月薪水作为违约金。 九、本协议未尽事宜应由甲、乙双方本着友好的原则协商解决。

2020年猎头服务合同(一)

2020年猎头服务合同(一) 更多精彩专题请访问:农副产品购销合同产品购销合同工矿产品购销合同出口产 品购销合同产品购销合同模板电子产品购销合同工业产品购销合同农产品购销合同 水产品购销合同钢材产品购销合同 ①签订双方商妥订货产品总值人民币____元。其产品名称的规格、质量、数量、单价、总值、交货付款等详如附表。 委托方:____________________(以下简称甲方) 代理方:_________人才服务部(以下简称乙方) 甲方(签章):_______________________ 乙方(签章):_______________________ 法定代表人:_________________________ 身份证号码:_________________________ 地址:_______________________________ 联系电话:___________________________ 邮政编码:___________________________ 代理人:_____________________________ 联系电话:___________________________ 甲方因业务发展需要,委托乙方搜索所需人才。经双方友好协商,达成以下合作条款: 出租方:___________________________ 地址:_____________________________ 邮码:_____________________________ 电话:_____________________________

法定代表人:_______________________ 职务:_____________________________ 第六条争议解决 6-1 因履行本合同或与本合同有关的一切争议,双方当事人应通过友好协商方式解决。 6-2 如果协商未成,双方同意向____________仲裁委员会提交仲裁并接受其仲裁规则。 6-3 如非乙方原因引起的单方面终止合同行为,款项不予以退回。 第一条主旨 本合同目的在于确定乙方代表甲方搜索候选人时双方的权利及义务。 第二条搜索服务的基本方式 1.甲方需提供与所需搜索职位有关的详细资料给乙方,其中主要包括: --工作环境,如公司背景、现状(规模、发展状况、目前和将来的投资等); --职务名称、职位职责,个人发展前景、直属上司情况及汇报路线; --所须具备的条件(包括年龄、性别、教育程度、英文程度、专业经验以及个人品性); --工作中所需要的独立性、工作氛围,流动性(出差需要)和上班地点等; --福利待遇(包括基本工资、奖金和津贴、工作时数、生活条件以及合同保险)。 2.乙方工作程序: --搜索可能达到该标准的候选人,对这些候选人进行初次面试筛选并确证其资料的真 实性; --将候选人资料提交甲方参考,包括对其经验的评价及对其性格,能力和潜质的看法;

猎头合同模板

合同编号: 高级人才寻访服务合同 甲方: 地址: 电话: 邮箱: 乙方: 地址: 电话: 传真: 甲、乙双方在平等自愿、协商一致的基础上,就甲方委托乙方寻访和推荐优质人才等事宜,达成如下条款,以共同遵守: 一、服务内容 1.1甲方委托乙方按照甲方提供的职位描述要求寻访人才,接受乙方的推荐,并安排面试。 1.2乙方通过各种渠道搜寻符合甲方职位要求的合适候选人,并推荐给甲方,以满足甲方人 力资源方面的需求。 1.3当乙方所推荐的候选人通过甲方面试,并在甲方所指定的岗位上报到后,该服务主体结 束。但是乙方有义务提供合同所承诺的人员更换服务义务。 二、服务期限 本合同自双方签字起生效,合同有效期为年,自年月日至年月日。 三、甲方的权利和义务 3.1 该职位委托合同甲方委托乙方为其代理招聘服务,。 3.2 甲方须尽可能详细明确的填写《委托猎头登记表》,以及提供委托职位的职位描述。甲方应根据项目进度及乙方服务规程要求,给予乙方项目顾问尽可能详尽的信息支持与配合,以便乙方寻访适合甲方的候选人; 3.3甲方应在乙方推荐人员到职后三个工作日内书面通知乙方。如在聘用通知书约定的上班之日,乙方推荐的人员未能到甲方上班的,甲方应将该情况发生后当日内书面通知乙方;3.4甲方应在与乙方推荐人员签订聘用通知书后五个工作日内将所聘人员职位、到职日期、薪酬、试用期等情况以书面形式通知乙方; 3.5甲方应对乙方提供的人员资料保密,并严格控制内部人员知情范围,不得向外泄露人才资料,或向任何第三方提供人才资料(包括个人和法人)。如有上述情况,一经核实,甲方需无条件给予乙方相应的经济赔偿;

3.6甲方对乙方的任何投诉和建议均可通过发送邮件到邮箱,甲方的投诉和建议将反馈给乙方相关部门。 四、乙方的权利和义务 4.1 甲方填写委托登记表、签订委托招聘服务合同后,乙方开始正式提供合同约定服务; 4.2 乙方应在签订合同后的10个工作日内,向甲方提供书面或电子邮件形式的,与委托职位相适合的有关候选人资料报告; 4.3 乙方自签订本合同起,不得将甲方内的工作人员、商业信息,推荐或泄露给其他可能获得利益的第三方;在本协议到期或终止后,以上保密责任依然存在。 4.4 乙方不得将其推荐给甲方并被成功聘用的人选再次推荐给其它任何客户; 4.5 乙方承诺提供人员更换服务如下:如乙方推荐的候选人在正式报到日起3个月内离职,甲方在被推荐人选离开之日起10个工作天日内以书面形式将该情况通知乙方,乙方应就此职位按甲方要求无偿提供另外人选。新人选入职后,乙方将重新计算保证期并继续承担人员更换服务义务。如果被录用者的工资福利、岗位职位等未能按甲方与候选人事先约定之标准实施,或者遇甲方因办公场所搬迁、重大人事调整所导致的非人选自身原因而导致被录取者离职的,由甲方承担对该被录取者的相关责任,乙方不承担人员更换服务义务; 4.6 任何乙方向甲方所推荐的人员,自被推荐之日起十二个月内,均被视为“乙方推荐人员”,在此期间内,如乙方证实甲方或其子公司与被推荐人发生聘用与被聘用关系,视为乙方已成功推荐,甲方须按本合同支付全额费用; 4.7 自“乙方推荐人员”被推荐予甲方之日起十二个月内,甲方不得就聘用事宜向任何第三方(不包括甲方各分支机构)推荐。 4.8 在合同期内,乙方不得向甲方在职员工推荐任何职位机会。 五、服务费用及付款方式 5.1 成功聘用乙方推荐的候选人后,甲方须向乙方按每人每一职位支付服务费用标准为被雇佣者第一年税前年薪总收入的。被雇佣者年薪总收入包括基本工资、奖金、提成及其他各类现金支付的福利和补贴; 5.2 本合同所称的成功聘用有下述两种情况: 1)甲方与乙方推荐的候选人签订了《劳动合同》或者该候选人员已实际在甲方工作 (含试用期); 2)包括但不限于甲方与乙方推荐的候选人以顾问或者兼职的形式产生合作关系。 5.3 服务费支付方式如下:乙方推荐的候选人被甲方成功聘用后乙方应向甲方发出付款通知书,甲方应在收到付款通知核实无误后的十个工作日内支付服务费用的。候选人通过三个月试用期之后,乙方应向甲方发出付款通知书,甲方应在收到付款通知核实无误后的十个工作日内支付服务费用的30%。如金额有误,甲方应在收到付款通知后两个工作日内通知乙方;乙方未收到甲方书面的异议通知的,视为甲方确认该付款通知书。 5.4 乙方在提供本合同约定的服务时实际发生的所有费用,如广告费,差旅费等须经甲方事先书面同意,方可由乙方向甲方收取。如甲方延期付款超过天,乙方有权要求甲方及时付清服务费,每天按服务费的加收滞纳金。

猎头协议正式版

The cooperation clause formulated through joint consultation regulates the behavior of the parties to the contract, has legal effect and is protected by the state. 猎头协议正式版

猎头协议正式版 下载提示:此协议资料适用于经过共同协商而制定的合作条款,对应条款规范合同当事人的行为,并具有法律效力,受到国家的保护。如果有一方违反合同,或者其他人非法干预合同的履行,则要承担法律责任。文档可以直接使用,也可根据实际需要修订后使用。 甲方:_____ 乙方:_____ 1.公司指定 根据本合同协议和条款,乙方委托并指定甲方为乙方提供本合同规定的各项咨询服务。 2.双方关系 甲方和乙方均为独立法人。本合同的签订在甲方和乙方之间并不产生任何雇用、代理、合资或业务伙伴关系。甲方绝非乙方的法律代表,无论是任何目的,甲方均不能以书面或其它明示或隐含方式,

以乙方的名义享受权利或承担义务。 3.服务 甲方将根据乙方提供的职位要求向乙方推荐合适的人选。具体职位描述、要求及人数由乙方提供,详细的书面材料作为本协议的附件一,具有同等法律效力; 甲方应确保每一个推荐给乙方的候选人首先经过甲方的面试筛选。若乙方要求,甲方应对候选人简历中包含的信息或候选人提供的其它信息的准确和真实性及在面试过程中发现的问题进行核实。 凡经甲方推荐的人才,从推荐之日起12个月内,如果乙方未通过甲方暗地或通过第三方录用该人才,无论长期或短期,均视为甲方推荐成功,乙方按照本合同相

人才推荐服务合同范本

编号:_____________ 人才推荐服务合同 甲方:___________________________ 乙方:___________________________ 签订日期:_______年______月______日

甲方: 乙方: 鉴于甲方业务需要,特委托乙方为其推荐、寻访甲方所需招聘职位,经双方友好协商一致,达成如下一致协议: 1.岗位名称及收费标准(人民币) 1.1委托职位名称: 具体职位要求,详见附件《企业职位需求表》。 1.2招聘服务费:按税前年薪的30%收取(以实际录用薪资为准) 2.甲方需提供与所需搜索职位有关的详细资料给乙方(见附件1:企业职位需求表),其中主要包括: ——工作环境,如公司背景、现状(规模、发展状况、目前和将来的投资等);——职务名称、职位职责,个人发展前景、直属上司情况及汇报路线;——所须具备的条件(包括年龄、性别、教育程度、英文程度、专业经验以及个人品性); ——工作中所需要的独立性、工作氛围,流动性(出差需要)和上班地点等;——福利待遇(包括基本工资、奖金和津贴、工作时数、生活条件以及合同保险)。 3.乙方提供的服务 3.1在合同签订后的10-15个工作日内,乙方向甲方采用电话或书面调查报告方式,提供甲方指定人选的相关情况; 3.2若甲方指定候选人无意愿服务甲方企业,经双方协商后,乙方在合同期内找

到合适的候选人,可随时向甲方提供。 3.3若乙方第一次推荐的人员不符合甲方要求,经双方沟通后,共同修改和调整职位要求(例如职位要求过于求全或该职位对符合条件的高端人才无吸引力)和扩大搜索范围,以便于乙方尽快推荐下一批候选人。 3.4乙方的顾问将全权负责与候选人的联系,安排面试等事宜。在乙方授权之前,甲方不得与候选人直接联系。 3.5在双方合作期间,如甲方自行招聘到合适人员后(非乙方推荐人选),需在3日内以电子邮件形式通知乙方,则双方就该岗位的合作约定自动取消。 4.付款条件和方式 4.1每个职位的招聘费用分为预付款和猎头服务成功费两部分,甲方分别在不同的时期付给乙方。 预付款为总服务费的30%即人民币 /人,应当在乙方与甲方签订合同日起七天之内支付。如因甲方原因提出取消现有职位的寻访,预付款不予退还。猎头服务成功费,为总费用减去已付的预付款后的数额。费用支付时间为候选人正式上岗日起7个工作日内。如果甲方迟延付款超过10个工作日,甲方应向乙方支付滞纳金,滞纳金的计算方式为:应付未付的服务费х0.5%х迟延天数(从上述付款期后的次日起开始计算直至付清款项日)。 4.2以上付款,甲方应在规定日期内将所有应付款支付给乙方,乙方应于甲方支付各项费用后的7个工作日内向甲方提供相应的发票。 4.3若遇本合同3.5的情形,甲乙双方合同解除,则甲方应支付的预付金,乙方不予退还。 4.4任何代表甲方所发生的费用应在事先得到甲方同意的情况下,向甲方收取,

猎头公司双向合作协议书简易版

It Is Necessary To Clarify The Rights And Obligations Of The Parties, To Restrict Parties, And To Supervise Both Parties To Keep Their Promises And To Restrain The Act Of Reckless Repentance. 编订:XXXXXXXX 20XX年XX月XX日 猎头公司双向合作协议书 简易版

猎头公司双向合作协议书简易版 温馨提示:本协议文件应用在明确协议各方的权利与义务、并具有约束力和可作为凭证,且对当事人双方或者多方都有约制性,能实现监督双方信守诺言、约束轻率反悔的行为。文档下载完成后可以直接编辑,请根据自己的需求进行套用。 甲方(委托人):______________ 委托代理人:__________ 乙方(受托人):______________ 依据国家法律、法规和本市政府部门有关规定,甲、乙双方在平等、自愿和协商一致的基础上,就甲方委托乙方从事房屋出售代理事项达成一致,订立本合同。 第一条委托事项 1.甲方委托乙方代理出售位于_______市_______区______房产,建筑面积_________平方米(以房屋产权证登记面积为准),权属性质__________,产权证号__________,产权人

__________,随房屋一并出售室内装饰、附属设施以及_________。 2.乙方为甲方售房广告策划、寻找客户、洽谈、促成交易、办理房屋权属变更事宜3.乙方在委托范围内,就上述房产与购房人签订的合同,甲方均确认。 第二条委托代理期限 乙方自本合同订立之日起______个工作日内为甲方找到购房客户。办理房屋权属变更,按照房屋所在区县有关部门的规定期限执行。如因甲方原因耽误,工作日相应顺延。 第三条房产价格及付款方式 1.该房产委托出售价格为人民币(大写)__________元(¥__________)此价格为税前款。

猎头公司服务合同

猎头服务合同 委托单位(以下简称甲方): 代理单位(以下简称乙方): 甲方因业务发展需要,委托乙方猎聘所需人才,经双方友好协商,达成如下合约: 第一条招聘内容 第二条甲方的权利义务 1、甲方必须向乙方提供真实详细的企业背景资料和招聘的《职位描述报告》。 2、甲方对乙方推荐的候选人进行面试后,必须在3个工作日内给出是否录用该候选人的意见。 3、甲方不得利用候选人获取候选人违反其与原工作单位签订的保密协议规定的保密义务,因甲方利用候选人 获取原单位保密信息而引起的任何后果由甲方独自承担,与乙方无关。 4、甲方作为雇主应当对自己雇员的最终选择、录用、持续工作监管承担全部责任,对于推荐候选人所引起(或 相关)的对甲方造成的损失、损坏或费用等将由甲方自行承担,乙方不承担任何相关责任。 5、合约履行过程中,如甲方变更招聘其他岗位,或取消该岗位的招聘要求,或延缓聘用适用该岗位的候选人 的,乙方有权单方面解除本合约,预付款不予退还。 6、甲方承担候选人面试所产生的所有差旅费用,定向猎取或乙方随同甲方外出洽谈、面试,甲方须为乙方支 付定向所在地猎聘往返差旅费。 7、对于乙方所推荐的候选人的相关资料,甲方不能作为其他用途并负有保密的义务,否则赔偿相应损失,甲 方若将乙方推荐的候选人转给其它第三方并产生聘用的,视为乙方已完成服务工作并支付相关服务费用。 第三条乙方的权利义务: 1、乙方承诺保证不猎取甲方在职人员,并保守甲方公司的机密。 2、乙方按照甲方《职位描述报告》进行人才搜寻、面试,并对甲方公司的招聘信息严格保密。 3、乙方为甲方提供详尽的猎头人才评估推荐报告,为甲方面试提供专业的岗位人选和用人建议。 4、乙方协助甲方与候选人进行薪酬谈判、到岗日期等促进招聘工作,协助甲方与人才签定劳动合同,并进行 后期人才的跟踪服务,如果被录取者的工资福利等未能按甲方与人才事先约定之标准实施,而导致被录取 者离职的,乙方不退还预付款和服务费,并由甲方承担由此而来的一切责任。 5、乙方在服务期内(60个工作日)内未能向甲方推荐候选人或候选人不符合《职务描述报告》要求,甲方有 权终止本合约,乙方退还本岗位全额已收预付款。 6、乙方推荐的候选人,甲方面试后因某种原因不能长期或专职聘用该候选人,而委托该候选人担任兼职或 其它短期服务,同样视为乙方已完成服务工作,甲方须支付相应的服务费用。 7、本协议签订后,甲方鼓动、引诱、劝说乙方推荐的候选人绕开乙方私下签订劳动合同或变更劳动合同的 薪酬标准的,视为乙方已完成服务工作,甲方须支付相应的服务费用。

猎头服务合作协议书

猎头服务合作协议书 甲方(委托方): 地址: 乙方(受托方): 地址: 甲、乙双方本着互利互惠、平等自愿、有偿服务的原则,就甲方委托乙方代为搜索、甄选、推荐各类种人才等事宜,经充分协商,达成如下协议,以资共同遵守: 一.合同有效期:从______ 年—月—日至__________ 年—月—日。 二.甲方的权利与义务 1. 甲方必须向乙方提供本企业营业执照复印件、公司简介、委托招聘的相关信息。 2. 甲方应按乙方要求提供所需的职位需求信息,并保证寻猎职位信息的真实性,所提要求及待遇 标准,必须按标额执行。如在委托期内,寻猎需求有任何更改应及时通知乙方。 3. 甲方负责对乙方提供的候选人资料进行筛选,对符合初选条件的人,乙方负责协调候选人到甲 方进行面试。 4?如甲方发现乙方提供的人选资料与其他招聘渠道所提供的资料重合时,且甲方从乙 方处获得候选人姓名、联系信息之前,或要求乙方安排候选人面试之前,应在收到乙方人选资 料后5个工作日内提出申明,并出具相关的资料证明,否则即视为认可。 5. 甲方按照公司 的相关面试流程对乙方推荐的候选人进行面试,在面试流程结束后,5 个工作日内告知乙方面试结果。 6. 甲方按时向乙方支付服务费。 7. 在本协议有效期内或本协议终止后十二个月内,甲方聘用乙方推荐的人才的,甲方应于聘用前通知乙方,并按 照本协议第3条规定向乙方支付服务费。甲方聘用乙方推荐的人才但未按前述规定履行通知义务的,甲方除应向乙方一次性支付全额服务费外,应向乙方支付服务费的两倍作为违约金,且甲方聘用的 乙方推荐人才的年薪视为30万元,甲方不得对此提出任何异议。若乙方发现其推荐的人才的年薪高于30 三.乙方的权利与义务 1. 乙方在双方签订委托招聘服务合同后,明确招聘岗位后,寻访和物色工作全面正

猎头服务合同模板

猎头服务合同模板文件编号TT-00-PPS-GGB-USP-UYY-0089

企业招聘服务合同 甲方:安捷利(番禺)电子实业有限公司 地址:广东省广州市南沙区环市大道南63号 联系人:温小姐 /罗先生 电话: / 邮箱:传真:乙方:地址:负责人:电话:邮箱:传真: 甲乙双方经友好协商,就乙方为甲方提供招聘服务相关事宜,一致达成如下合同条款,以共同遵守: 一、服务内容 1. 甲方委托乙方按照甲方提供的职位需求,为其进行人力资源引进推荐服务。 2. 本合同中所述委托是指甲乙双方书面(包括但不限于下述形式:合同、协议、信件、传真、电子邮件等)确认甲方需要乙方猎寻的职位以及该职位所需要的关键要求,上述委托可为本合同附件,与本合同具有同等法律效力。

3. 合同期限为:本合同有效期为一年,自签字盖章之日起生效,每年合同到期前经双方书面约定可延续本合同一年。 二、甲方权利义务 1. 甲方须向乙方提供真实的企业相关背景资料。 2. 甲方须配合乙方对推荐的候选人进行面试。 3. 甲方应在与乙方推荐人员签订聘用通知书后三个工作日内,将所聘人员职位、到职日期、年薪、试用期等情况以书面或电子邮件形式通知乙方。 4. 甲方应在乙方推荐人员到职后三个工作日内以书面或电子邮件形式通知乙方。 三、乙方权利义务 1. 乙方严格按照甲方提供的岗位说明书对人才进行搜寻,每个岗位提供的候选对象不得少于三人。 2. 乙方对初选合格人员进行面试并核准相关证明资料和工作经历。 3. 乙方负责与甲方沟通确认甲方面试的时间、地点,并进行相关人才的联络服务工作。

4. 乙方协助甲方进行人才聘用合同的最终签定。 5. 乙方承诺提供候选人更换服务如下: 1) 甲方需支付完乙方服务费。 2) 如乙方推荐的候选人在正式上岗日起保证期三个月内离职,甲方在被推荐人离开之日起三个工作日内以书面或电子邮件形式通知乙方,乙方为甲方免费提供一次相同岗位的人才推荐至成功聘用服务。 3) 乙方在补充推荐新候选人期间,甲方自行找到合适候选人,或者乙方没寻访到合适候选人替代,乙方承诺将相当于该职位服务费的50%用于冲抵合同期内其它成功招聘职位的相应金额服务费,如果合同期满双方未再有成功招聘的职位而造成无法冲抵,则乙方承诺将该职位服务费的50%退还给甲方。 4) 如果被录用者的工资福利、岗位职位等未能按甲方与候选人事先约定之标准实施,或者遇甲方因办公场所搬迁、重大人事调整所导致的非人选自身原因而导致被录取者离职的,由甲方承担对该被录取者离职的相关责任,乙方不承担人员更换服务的义务。 6 . 本合同期内,乙方不得向甲方在职员工推荐任何职位机会。

猎头协议(招聘服务协议)-中英文

委托招聘服务协议 Placement Service Agreement 甲方: Party A: 联系人/Contact: 电话/Tel: 乙方: Party B: 联系人/Contact: 电话/Tel: 鉴于甲方业务发展的需要,甲方非独家委托乙方进行人才咨询及代理招聘、推荐服务。经友好协商签订如下协议,双方约定共同遵守。 Party B is non-exclusive agent for Party A’s recruitment; this contract is ruled to Party B’s service in talents consulting and placement for Party A. The Parties hereby agree as follows: 一、甲方的权利和义务Party A’s Rights and Responsibilities 1.甲方应严格执行国家的有关人事政策、法律法规。 Party A must observe China’s relevant personnel policy, regulation s and laws. 2.甲方有权要求乙方根据本协议之规定为甲方提供所需职位的候选人,并应依照本协议的规定向乙方支付服务费。 Party A has the right to require Party B to provide candidates for the opened position/s as defined and specified by Party A, and Party A shall make payment of a service fee to Party B as defined and regulated in this Agreement. 3.每一职位正式委托(书面)后的5个工作日内,甲方应向乙方提供寻访职员所需的相关信息及材料,并保证其真实性和合法有效性,包括但不限于:职位要求、工作描述、公司简介、组织机构图、可能的薪金福利情况等,以便乙方在访寻过程中确认潜在的候选人,并使候选人对公司和工作进行充分和必要的了解。 Within 5 working days of entrusting placement job in writing, Party A should provide Party B with all the information, data and documents as deemed necessary for Party B to start working on the placement job, which include but not limited to the following: Profiles of the organization, Organization chart as related to the placement job, Job description/s,

猎头公司双向合作协议书样本(标准版).docx

编号:_________________ 猎头公司双向合作协议书样本 甲方:________________________________________________ 乙方:________________________________________________ 签订日期:_________年______月______日

甲方: 乙方: 甲乙双方本着共同协商、合作事宜,一致同意签订本协议: 一、甲乙双方本着资源共享,双赢合作的原则本着诚信合作的意愿进行双边合作。 二、甲方受企业委托与乙方进行双向猎头合作业务时,须提供营业执照复印件,仔细填写《委托招聘需求表》对所委托的职位进行详细的描述,提供企业真实的经济性质、规模大小、发展前景等情况,以便使乙方正确理解委托招聘岗位的要求和客观负责的向候选人介绍聘方的情况。 三、乙方在双方协商的时限内,为甲方提供符合要求的人才信息,供甲方选择;甲方对选中的推荐人选进行面试,录用权在甲方(必要时乙方可与甲方一起面试参与人才与企业的面试)。 四、甲方对乙方提供的人员进行面试后的两个星期内应明确通知乙方是否录用。甲方在与面试人员达成一致,明确表示录用乙方推荐人选之后,在推荐人选上班前,支付乙方成功推荐的服务费,金额为每一位人选年薪的____%。人才上岗一个月后

付清人才全部薪资的____%。 五、如果乙方推荐给甲方的人选____个月内,因种种原因离职,那么在该人选解聘后,乙方应该无偿继续为甲方推荐合适人选若一个月内仍然未能找到合适人选,除非甲方要求继续推荐,否则甲方有权要求乙方返还该人选推荐费的____%。( 甲乙双方各提取人才拥金的一半,费用也应由双方一同支付。) 六、双方要以“公开、公正、守信、诚意”为原则,共同遵守和实施以上委托事宜。甲方必须通过乙方录用乙方提供的人员,未经乙方同意,甲方不得在乙方不知情的情况下私下与被推荐人员联系或达成有损乙方利益的约定,经发现作违约处理。 七、凡乙方推荐的人员(按约定已向乙方支付全额推荐费用的人员除外),自推荐之日起一年内,甲方除非得到乙方的同意,否则不得以任何理由私自录用该人选。 八、乙方对违反本协议的任何行为保留一切法律行为的权力。一经发现,甲方在必须全额补偿乙方上述应付金额以外,乙方还有权要求甲方在发现违约之日起两星期内,支付乙方所推荐之人员五个月薪水作为违约金。 九、本协议未尽事宜应由甲、乙双方本着友好的原则协商解决。本协议一式二份,甲、乙双方各执一份。经甲、乙双方签字盖章后生效。甲方盖章后回传。谢谢! 注:如有不妥的地方可作修改,谢谢合作!

猎头合作协议范本

猎头合作协议范本 委托人:(以下简称甲方) 地址: 电话: 电子邮件: 受托人:(以下简称乙方) 地址: 电话: 电子邮件: 甲方委托乙方代理招聘人才,就有关事宜订立合同,目的在于确定甲乙双方的权利及义务,共同遵守如下条款: 一、甲方的权利和义务

1、甲方同意委托乙方猎聘________职位,猎聘佣金按该猎聘职位年薪的______%计算,该职位的猎聘佣金最低不得低于______元。该职位推荐周期为______个月。 2、甲方必须提供营业执照复印件、单位简介等所需文件协助乙方工作。 3、甲方如在乙方安排的初猎面试时不满意乙方报荐人才,可要求乙方重新推荐人才面试。 4、为保证乙方的工作顺利进行,甲方不能单独约见应聘者,面试由乙方安排见面,如有特殊情况约见应聘者,也必须通知乙方。 5、待甲方通过面试选定人才到岗后,人才到岗______个工作日内付猎头服务费用的______%,人才通过试用期后______个工作日内付其余______%的猎头服务费用。如甲方延期付款,每天按余款的百分之______作为滞纳金。 6、甲方在收到乙方发送的候选人资料当日,须以邮件形式反馈给乙方是否通过其他方式获得此候选人简历,如果当日没有回复给乙方信息,并私自约见、录用候选人,甲方除应支付乙方猎头服务费外,同时应承担猎头服务费的______%违约金,并在乙方得知此事后______个工作日内支付。若逾期支付,滞纳金每天为猎头服务费的 ______%。

7、在合作期内,甲方一经决定录用乙方推荐的候选人,应提供录用通知书复印件予乙方。否则,乙方有权利对该候选人进行其他推荐。 8、通过电话沟通,符合甲方职位要求的外地来甲方面试候选人如果要求才旅费的,由甲方承担。 二、乙方的权利和义务 1、乙方从双方签订协议起,寻访和物色工作全面正式开始,并且在每______个工作日内向甲方提交拟举荐的候选人的综合推荐简历(每一岗位的候选人为______名),直至甲方找到合适人选或本推荐周期结束。根据甲方反馈意见,乙方负责安排候选人与甲方面谈具体事宜,同时全程协助及引导性服务。 2、若乙方在受托后向甲方举荐的人选不符合甲方要求,乙方应继续举荐,直到甲方满意或甲方提出终止寻访通知为止;甲方提出终止寻访应以书面的形式通知乙方(如果甲方通过其他方式找到合适的候选人,甲方也应及时以书面形式通知乙方提出终止寻访)。 3、在乙方推荐的人选被甲方正式录用后,乙方承诺______年内不到甲方单位内猎取任何在职人员给其他客户。 4、乙方推荐给甲方的人才享有个______月保用期,保用期内候选人离开(包括但不限于辞职、辞退),甲方有权选择由乙方继续在

猎头服务合同模板

编号: HT-20214765 甲 方:______________________________ 乙 方:______________________________ 日 期:_________年________月_______日 猎头服务合同模板 The parties may dissolve the contract upon consensus through consultation.

[标签:titlecontent] 甲方(劳务用工单位): 工商登记号:联系地址:邮政编码:联系电话:传真:联系人:开户行:帐号: 乙方(劳务招聘单位): 工商登记号:联系地址:邮政编码:联系电话:传真:联系人:开户行:帐号: 甲、乙双方就乙方向甲方提供需求职位人才的寻访推荐服务达成如下合同(以下称“本合同”): 前言: 甲乙双方保证各自为依据中华人民共和国的相关法律法规合法成立的组织。乙方应确认有从事该项服务的资格,甲方应确认向乙方提供的各种资料的真实性,双方就各自的确认承担各自的法律责任。 甲、乙双方本着自愿和互惠互利的原则,合作签署“本合同”,并愿意自觉遵守“本合同”的各项条款。 第一条服务内容 1、甲方聘请乙方作为其中、高级人才推荐的供应商。

2、甲方如有招聘需求,应向乙方提供委托招聘职位信息,内容包括需求岗位职责描述、胜任条件、薪资福利条件、需求人数和日期等。 3、自甲方正式委托职位寻访之日起,乙方正式启动寻访推荐工作。15个工作日内向甲方推荐每个职位2—3名经过甄选基本符合甲方职位需求的候选人,直到甲方录用乙方所推荐的候选人为止。 4、乙方在推荐候选人时,需要向甲方提供人选的详细简历,说明其以往的工作经历、主要职责、成就以及能说明其工作胜任能力的任何其它必要资料。 5、甲方聘用乙方推荐的人员,在个月(保证期),自推荐人开始在甲方工作之日起,如发生聘用终止,乙方应为甲方免费提供一次相同职位的人才服务,乙方应保证在甲方通知乙方的15个工作日内为甲方再次提供候选人。 第二条限制 1、甲方不得提供虚假职位需求信息和做出虚假承诺。 2、合作期间甲方不得直接聘用乙方猎头顾问和工作人员,如有发生甲方应付乙方该职位应付猎头佣金的双倍的服务费用。 第三条保密原则 1、乙方应对甲方提供的任何商业、技术资料及员工信息进行保密。 2、甲方应对乙方提供的人选资料、服务费用保密,不得将乙方提供的人选资料用于任何非自己聘用内部员工的目的和提供给甲方

猎头服务合同书(标准版).doc

猎头服务合同书 委托方:____________________(以下简称甲方) 代理方:_________人才服务部(以下简称乙方) 甲方因业务发展需要,委托乙方搜索所需人才。经双方友好协商,达成以下合作条款: 第一条主旨 本合同目的在于确定乙方代表甲方搜索候选人时双方的权利及义务。 第二条搜索服务的基本方式 1.甲方需提供与所需搜索职位有关的详细资料给乙方,其中主要包括: --工作环境,如公司背景、现状(规模、发展状况、目前和将来的投资等); --职务名称、职位职责,个人发展前景、直属上司情况及汇报路线; --所须具备的条件(包括年龄、性别、教育程度、英文程度、专业经验以及个人品性); --工作中所需要的独立性、工作氛围,流动性(出差需要)和上班地点等; --福利待遇(包括基本工资、奖金和津贴、工作时数、生活条件以及合同保险)。 2.乙方工作程序: --搜索可能达到该标准的候选人,对这些候选人进行初次面试筛选并确证其资料的真实性; --将候选人资料提交甲方参考,包括对其经验的评价及对其性格,能力和潜质的看法; --为双方安排面谈时间、地点,并参与其中一些条款的协商,协助聘用合

同的最终签署; --协助甲方督促被录用候选人与原工作单位按正常的程序办好离职手续。 3.乙方在合同签定之日起天内完成对甲方所需人才的寻访、测评及背景调查,将完整、真实的候选人资料提交甲方,并安排候选人面试。 4.甲方应在收到乙方提供的候选人资料后两日内,做出是否与己有人才资料重复的判断,否则视为乙方推荐;甲方应在收到乙方提供的候选人才资料后一周内,做出是否需要复试的判断,甲方应在候选取人面试后两周内将面试意见及审核结果反馈给乙方,在复试后四周内做出是否录用的判断。 第三条保证期 1.推荐的候选人被甲方录用,并最终到甲方工作,视为猎头服务成功。 2.雇员在保证期(三个月) 内无论因任何原因离职,甲方应五天内向乙方提出书面报告,乙方将免费为甲方推荐另一合适候选人到职;乙方收到甲方书面报告后二个月内没有推荐合格人选到职,乙方应退还该项服务费的_______%。 3.甲方一经决定录用乙方推荐的候选人,应向乙方提供录用确认书复印件;录用确认书应包括候选人的录用工资、上班报到日期、工作职责等;否则,乙方将不能履行保证期的约定。 第四条收费标准 1.合同签订后,甲方须支付定金,定金为人民币_______元,该笔定金可抵入服务费;如因甲方原因而取消该职位的招聘,定金不予退还。 2.甲方录用乙方推荐的候选人后,须向乙方支付人民币_______元作为招聘服务费用。

猎头公司双向合作协议书(正式版)

YOUR LOGO 如有logo可在此插入合同书—CONTRACT TEMPLATE— 精诚合作携手共赢 Sincere Cooperation And Win-Win Cooperation

猎头公司双向合作协议书(正式版) The Purpose Of This Document Is T o Clarify The Civil Relationship Between The Parties Or Both Parties. After Reaching An Agreement Through Mutual Consultation, This Document Is Hereby Prepared 注意事项:此协议书文件主要为明确当事人或当事双方之间的民事关系,同时保障各自的合法权益,经共同协商达成一致意见后特此编制,文件下载即可修改,可根据实际情况套用。 甲方(委托人):______________ 委托代理人:__________ 乙方(受托人):______________ 依据国家法律、法规和本市政府部门有关规定,甲、乙双方在平等、自愿和协商一致的基础上,就甲方委托乙方从事房屋出售代理事项达成一致,订立本合同。 第一条委托事项 1.甲方委托乙方代理出售位于_______市_______区______房产,建筑面积_________平方米(以房屋产权证登记面积为准),权属性质__________,产权证号__________,产权人__________,随房屋一并出售室内装饰、附属设施以及_________。

2.乙方为甲方售房广告策划、寻找客户、洽谈、促成交易、办理房屋权属变更事宜 3.乙方在委托范围内,就上述房产与购房人签订的合同,甲方均确认。 第二条委托代理期限 乙方自本合同订立之日起______个工作日内为甲方找到购房客户。办理房屋权属变更,按照房屋所在区县有关部门的规定期限执行。如因甲方原因耽误,工作日相应顺延。 第三条房产价格及付款方式 1.该房产委托出售价格为人民币(大写)__________元(¥__________)此价格为税前款。 2.如乙方低于委托出售价格卖出,差额部分由乙方负责补齐交付甲方;如乙方高出委托出售价格卖出,高出部分归乙方所有。 3.付款方式:现金支付/银行转账。 第四条购房定金、购房款及付款方式

人才猎头合同范本

人才猎头服务协议 甲方:xxxxxxxxxxxxxx 乙方:xxxxxxxxxxxxxxx 甲方因业务发展需要,特委托乙方以猎头服务方式招聘职位人选,甲乙双方本着“平等合作,互惠互利”的原则,经友好协商达成如下协议: 一、甲方权利与义务 1.甲方应向乙方提供详细、真实的公司背景资料,包括但不限于公司背景、经营状况、发展战略、企业文化等。 2.甲方须负责提供所需招聘岗位的详细资料,真实填写《企业职务需求表》(附件1),并对薪酬、福利、休假等与应聘者利益相关一切信息之真实性负责。 3.收到乙方提交的候选人报告资料后,甲方应在三个工作日内通知乙方是否要求候选人面试。如果面试,应提前告知时间和地点。面试结束后,甲方应在三个工作日内告知乙方面试结果。对不合适的候选人,应给出说明。如果不面试,应给出具体的不面试原因。 4.甲方应在面试后积极与乙方沟通、协调,三天内做出上一轮面试的决议(包括安排下一轮复试或录用)。特殊情况外,每个候选人面试次数最多为四次。 5.甲方对候选人信息、候选人报告、候选人面试过程等一切可能有损于候选人正当利益或本合同正当履行的信息,负有保密义务。 二、乙方权利与义务 1.乙方对甲方提供的企业、职位等信息负有保密义务。除为完成本合同所必须外,其余未经甲方授权,不得公开。 2.乙方需在寻访服务期(自年月日至年月日)内利用各种渠道为甲方寻访、招聘所需人才。乙方在了解候选人的情况,分析其背景资料,并在此基础上进行筛选

后,向甲方提交合适候选人的个人资料。如果在寻访期内,甲方未能对乙方提供的候选人给出明确答复,乙方有权终止合作。 3.若出现以下任何一种情况,均视为乙方已完成猎头服务全部工作,乙方有权要求甲方按本合同所列的“全职服务费用”,按约定支付周期与方式支付费用。如逾期支付,乙方将保留诉诸法律解决的权利: (1)甲方面试乙方所推荐的候选人后录用其作为甲方员工以全职合作; (2)甲方面试乙方所推荐的候选人后因某种原因不能提供所聘用岗位,但录取该候选人为其他岗位职员。 4.若出现以下任何一种情况,均视为乙方已完成猎头服务全部工作,乙方有权要求甲方按本合同所列的“全职服务费用”,在五个工作日内支付全额猎头服务费。如逾期支付,乙方将保留诉诸法律解决的权利: (1)甲方将乙方所推荐的候选人转荐给其他雇主,并且候选人被他雇主其聘用的; (2)甲方面试乙方所推荐的候选人后表示拒绝聘用,却在面试后一年内聘用乙方曾推荐的人选。 5.若出现以下任何一种情况,均视为乙方已完成猎头服务全部工作,乙方有权要求甲方按本合同所列的“兼职服务费用”,在五个工作日内支付全额猎头服务费。如逾期支付,乙方将保留诉诸法律解决的权利: (1)甲方面试乙方所推荐的候选人后因某种原因不能聘用该候选人,而聘用该候选人做兼职或其他短期服务; (2)甲方面试乙方所推荐的候选人后并没有聘用,而采用咨询、承包等方式与候选人保持合作关系。 三、服务费标准及支付方式 1.全职服务费用标准: □人民币万元(大写:)(岗位年薪标准)×%(年薪的百分比)。 □约定固定金额服务费用人民币万元。 说明:支付方式按双方协商约定,二选一。 若甲方提出的岗位薪酬是某一区间的,岗位年薪标准以区间上限为标准。

相关主题
文本预览
相关文档 最新文档