subsets ownedElement
subsets clientDependency
subsets client
subsets client
subsets supplier
<HTML><HEAD>
<META content="MSHTML 6.00.2900.2180" name=GENERATOR></HEAD>
<BODY>
<H1>Agent</H1>
<H2>Summary:</H2>
<P>An agent is an autonomous entity that can adapt to and interact with its environment..</P>
<H2>Description:</H2>
<P>An agent is a kind of Participant with some additional characteristics. Agents are autonomous, interactive and adaptative components. They are capable of acting without direct external intervention. They are able to communicate with the environment and other agents. They can learn and evolve over the time.</P>
<H2>Semantics:</H2>
<P>No additional semantic.</P>
<H2>Semantic Variation Points:</H2>
<P>No.</P>
<H2>Issues:</H2>
<P><EM>- I think that we need to better justify the need of this element, because it belongs to a kind of platfrom and therefore it shuold be moved to an extension.</EM></P>
<H2>Examples:</H2>
<P><EM></EM> </P>
<H2>Metamodel:</H2>
<P><EM></EM> </P>
<H2>Profile:</H2></BODY></HTML>
<HTML><HEAD>
<META content="MSHTML 6.00.2900.2180" name=GENERATOR></HEAD>
<BODY>
<H1>Attachment</H1>
<H2>Summary:</H2>
<P>A part of the message that has its own identity and which is separable from the main message. Attachments are usually created and processed by components or applications external to the participants in the service.</P>
<H2>Description:</H2>
<P>The objective of Attachment is to allow the definition of elements in the messages that have their own identity and which are separable from the main message. Examples of attachments can be images, word documents, pdf documents, or music samples. </P>
<P>Attachments are usually created by external applications and are expected to be processed by external applications. </P>
<H2>Semantics:</H2>
<P>An attachment is an specialization of Property. It helps to distinguish between regular attributes that usually have an asociated dataype and attachments. Attachments are usually transmited in binnary format following a given encoding scheme. The encoding scheme can be defined in the encoding attribute.</P>
<H2>Semantic Variation Points:</H2>
<P>No semanticVariation Points.</P>
<H2>Issues:</H2>
<P><EM>- no</EM></P>
<H2>Examples:</H2>
<P><EM></EM> </P>
<H2>Metamodel:</H2>
<P><EM></EM> </P>
<H2>Profile:</H2></BODY></HTML>
<HTML><HEAD>
<META content="MSHTML 6.00.2900.2180" name=GENERATOR></HEAD>
<BODY>
<H1>MessageType</H1>
<H2>Summary:</H2>
<P>.MessageTypes identify the information that is exchanged between services providers and consumers.</P>
<H2>Description:</H2>
<P>A MessageType allows to explicitly identify the information to be exchanged through the services. Their usage is optional, as it is also possible to identify the messages exchaged from the signature of the operations of the ServiceInterfaces.</P>
<P>Their usage can be useful to identify those information structures that are specially sensible, and which cannot be changed without affecting the interaction of the Participant with other Participants. </P>
<P>MessageTypes can be used to describe input, output and exception messages.</P>
<H2>Semantics:</H2>
<P>No.</P>
<H2>Semantic Variation Points:</H2>
<P>No.</P>
<H2>Issues:</H2>
<P><EM>- I am not too sure about the need for this element, I am almost sure that we can use classes to describe the information exchaged, with only one doubt: the references. Ussually, the objects are passed as references, but that is to useful in services. We can use this messageType to reflect that the object is pass by value. The next question then, is what happens with the objects referenced from the object... </EM></P>
<P><EM>- maybe it can be useful to explicitly identiy the messages exchanged by the services and the requisitions.</EM></P>
<H2>Examples:</H2>
<P><EM></EM> </P>
<H2>Metamodel:</H2>
<P><EM></EM> </P>
<H2>Profile:</H2></BODY></HTML>
<HTML><HEAD>
<META content="MSHTML 6.00.2900.2180" name=GENERATOR></HEAD>
<BODY>
<H1>Milestone</H1>
<H2>Summary:</H2>
<P>A Mileston isa means for depicting progress in behaviours in order to analyse liveness. Milestones are particularly useful for behaviours that are long or even infinite.</P>
<H2>Description:</H2>
<P>A milestone depicts progress by defining a signal that is sent to an imaginary observer. The signal contains an integeer vaule that intuitibelu represents the amount of progress that hass been achieved when passing a point attached to this milestone.</P>
<H2>Semantics:</H2>
<P>The milestones are used to annotate certaint points in the bahavioural descriptions of the services.They can be used in the behavioural description of the ServiceArchitectures, ServicesContracts, Participants and ServiceInterfaces.</P>
<P>The Milstone can be understood as a signal. The signal is sent to an observer each time that a point connected to the Milestone is passed during execution. The implementation of the Milestones in the final execution environment is not mandatory, it is only advisable in those cases where there is an interest on monitoring the progress of the execution of certain behaviours.</P>
<H2>Semantic Variation Points:</H2>
<P>No.</P>
<H2>Issues:</H2>
<P><EM>- interesting but maybe not central to the objective of the metamodel. Maybe another extension on monitoring.</EM></P>
<H2>Examples:</H2>
<P><EM></EM> </P>
<H2>Metamodel:</H2>
<P><EM></EM> </P>
<H2>Profile:</H2></BODY></HTML>
<HTML><HEAD>
<META content="MSHTML 6.00.2900.2180" name=GENERATOR></HEAD>
<BODY>
<H1>Property</H1>
<H2>Summary:</H2>
<P>A .</P>
<H2>Description:</H2>
<P>The objective of .</P>
<H2>Semantics:</H2>
<P>A .</P>
<H2>Semantic Variation Points:</H2>
<P>No semanticVariation Points.</P>
<H2>Issues:</H2>
<P><EM>- Why? What is the scenariy that is being addrssed?</EM></P>
<H2>Examples:</H2>
<P><EM></EM> </P>
<H2>Metamodel:</H2>
<P><EM></EM> </P>
<H2>Profile:</H2></BODY></HTML>
<HTML><HEAD>
<META content="MSHTML 6.00.2900.2180" name=GENERATOR></HEAD>
<BODY>
<H1>ServiceCapability</H1>
<H2>Summary:</H2>
<P>A ServiceCapability provides a simple way to discover and deocument a portfolio of services.</P>
<H2>Description:</H2>
<P>ServiceCapability may specify its capabilities using Operations or realized Intefaces, and may contain ownedBehaviors indicating how the service capabilities might be implemented in order to discover and identify other services.</P>
<H2>Semantics:</H2>
<P>A ServiceCapability may realize interfaces, or contain operations that list the necessary service capabilities. A ServiceCapability may also have ownedBehaviors which may be used to indicate how other ServiceCapability might be expected to be used to implement the service capabilities. These are primarily used to identify and document services. </P>
<P>A ServiceCapability is connected to ServiceInterfaces or Participants that realize it through a UML2 Realization. Like any other classifier, a ServiceCapabiltiy may be marked as a specification which may or may not be realized by some implementing ServiceCapability. </P>
<P>A ServiceCapability may also be used as a part in a Participant to which its services may be delegated for implementation purposes.</P>
<H2>Semantic Variation Points:</H2>
<P>No semanticVariation Points.</P>
<H2>Issues:</H2>
<P><EM>- what is this for? It seems the ServiceInterface with <<specification>> stereotype</EM></P>
<H2>Examples:</H2>
<P><EM></EM> </P>
<H2>Metamodel:</H2>
<P><EM></EM> </P>
<H2>Profile:</H2></BODY></HTML>
<HTML><HEAD>
<META content="MSHTML 6.00.2900.2180" name=GENERATOR></HEAD>
<BODY>
<H1>Participant</H1>
<H2>Summary:</H2>
<P>A Participant (Fig 01.Simple) is a special kind of UML Component and Class that provides or consumes services. It represents an element of the system, or the system itself, that interacts with other entities outside the boundaries of the system. </P>
<H2>Description:</H2>
<P>Participants are used to distinguish regular elements (Components and Classes) from those that maintain relationships with entities outside the boundaries of the system. For example they can be used in the design of a supply chain management system to differentiate those parts, or Components, that exchange information with other organisations. Participants can also be used to identify the different organisations taking part in a complex business transactions.</P>
<H2>Semantics:</H2>
<P>As a UML Component the participant represents a modular part of a system <EM>(Fig 01.Simple)</EM> that encapsulates its contents and whose manifestation is replaceable. In the same way that components can, the Participant can package other UML elements to support its definition and to organise the model <EM>(Fig 09.ComposedParticipant)</EM>. </P>
<P>Participants may act as service consumer, providers or both. A participant will act as pure consumer if it only owns Requisitions and no Services <EM>(R 6.5.12.1)(Fig 03.Consumer)</EM>. On the other hand it will act as a pure provider if it only owns Services and no Requisitions<EM> (R 6.5.13.1)(Fig 02.Provider)</EM>. </P>
<P><EM>(Services/Requests)</EM> When a ConnectableElement (Service or Request) is added to a Participant, this implies that the Participant is able to provide or consume the capabilities defined that ConnectableElement. The capabilities can be specified Interface or ServiceInterface type of the ConnectableElement, or by the Contracts supported by that ConnectableElement. It is important to remark that when the Participant Services a ServiceInterface (or regular UML Interface) that means that the Participant is able to provide the provided interfaces and consume the required interfaces (This is because the Participant is acting as the Providerr of the ServiceInterface). The situation is different when a Participant Request a ServiceInterface. In that case that means that the Participant is able to consume the provided Interfaces and provide the required Interfaces (This is because the Participant is acting as the consumer of the ServiceInterface).</P>
<P><EM>(ServiceInterfaces)</EM> The Interfaces or the ServiceInterfaces implemented by the Participant are referenced through ConnectableElements (Services or Requisitions). When a ServiceInterface is pointed through a ConnectableElement that means that the Participant must implement the operations of the ServiceInterface and must comply with the behaviour of the ServiceInterface.</P>
<P><EM>(Contracts)</EM> Participants can indicate the service contracts they fulfill <EM>(R.6.5.6.1)</EM> and the roles they implement on those contracts. There are several ways to specify this relationship. It can be done in the context of a service architecture<EM> (Fig 04.ContractFulFillServiceArchitecture)</EM> or it can be done in the context of a participant <EM>(Fig 05.ContractFulFillParticiopant)</EM>. The implication of this binding is that the participant should, or must <EM>(R.6.5.6.2)</EM> (in case the Contract is Strict), implement all the responsabilities specified in the contract for the linked role. For example, if the role type is a service interface, the participant should (or must) provide that service interface complying with the behaviour of the contract. If the role type is a participant, this participant should (or must) provide all the features of that participant complying with the behaviour of the contract. </P>
<P><EM>(Behaviour)(R6.5.14.1)(R6.5.14.1)</EM> Participant can include behavioural descriptions to describe the way in which the different Services and Requisitions are executed to complete the objective of the Participant. This specification do not constrain the way to describe the behaviour of the component. Any UML behavioural specification method can be used to describe the activity of the Participant. This includes, but not is not limited to, activities, interactions, state machines, protocol state machines, and/or opaque behaviours <EM>(Fig 06.Behaviuor)(09.BehaviourOperation)</EM>.</P>
<H2>Semantic Variation Points:</H2>
<P> </P>
<H2>Issues:</H2>
<P><EM>- I use composition following the same approach that the one used between port and structuredclassifier and the same that the one between encapsulatedclassifier ans port. Latter in the profile we use the shared agregation because otherwise, if we use composition, it marks it as an error</EM></P>
<P><EM>- Why the requisitions and services properties are derived?</EM></P>
<P><EM>- R.6.5.6.2 I think that what is strict is the binding not the contract or the collaboration use. In the requirements for contracts there are no references to strict attributes. Therefore I will propose to add a new element <STRONG>ContractFulfillment</STRONG> to gather that information.</EM></P>
<P><EM>- In the metamodel it inherits form component and Class but in the profile it only inherits from component. In which sceparios do we need to use classes instead of components.</EM></P>
<P><EM>- should we add something in the description to reflect that the way in which those properties (requsitions and services) are derived are the same ones that the ports for the encasulatingClassifiers in UML</EM></P>
<H2>Examples:</H2>
<P><EM></EM> </P>
<H2>Metamodel:</H2>
<P><EM></EM> </P>
<H2>Profile:</H2>
<P><EM></EM> </P>
<P> </P></BODY></HTML>
subsets clientDependency
subsets ownedElement
<HTML><HEAD>
<META content="MSHTML 6.00.2900.2180" name=GENERATOR></HEAD>
<BODY>
<H1>Request</H1>
<H2>Summary:</H2>
<P>A ConnectableElement through which a participant receives and provides all the information it needs to be able to provide its services.</P>
<H2>Description:</H2>
<P>The objective of the Request element is to make it possible to distinguish the main service or services of the Participant and those who are required in order to be able to provide the main services. For example a Purchasing company main service is the PurcheaseService, but in order to provide that service it may require other external services such as Invoicing, Scheduling or Shipping services <EM>(Fig Participant.Example.09.BehaviourOperation)</EM>.</P>
<H2>Semantics:</H2>
<P>A Request inherits from ConnectableElement. It is a ConnectableElement that can provide and request operations to external entities. It redefines the isUsage attribute of the ConnectableElement to true. That means that the Participant who owns the request is action as the consumer of the services.</P>
<P>More concretely, if the type of the Request is an Interface, the Participant must be able to consume that interface. In that case the Interface will be required by the ConnectableElement. If the type of the Request is a ServiceInterface, it means that the Interfaces realized by the ServiceInterface will be required by the ConnectableElement, and the Interfaces used by the ServiceInterface will be provided by the ConnectableElement .It is important to note that this semantic differs from the standard UML semantics for port and its types. </P>
<H2>Semantic Variation Points:</H2>
<P>No semantic variations points.</P>
<H2>Issues:</H2>
<P><EM>- If the request inherits from connectable element it does not inherit the provided and requred attributes from the port metaclass. Should we include an inheritance to Port? I think that possibly yes.<STRONG> -> No, because we need to be able to define the behaviour among the different requested and provided interfaces. Port is not a classifier and therefore it cannot define behaviour. We specify the behaviour through the type property of the UML:::connectableElement which inherits from UML:::TypedElement. A minor drawback, or consequence, is that we have to include an association between the participant and the request.</STRONG></EM></P>
<P><EM>- There are 3 ways to relate a ServiceInterface with a UML:::Port the type, the provide and the require attributes. I think that we should avoid the use of the type In the same way UML does, and focus in provide and require. <STRONG>-> We use the type in order to be able to define behavior among the different interfaces.</STRONG></EM></P>
<P><EM>- UML:::Port has an attribute call isService, it covers some, but not all the needs of our standards, Should we explain this somewhere? <STRONG>-> We do not use port, becasue it cannot contain behavioural specification</STRONG></EM></P>
<P><EM>- If we include several required and provided interfaces (or service interfaces) to a request. Is it possible to define the behabiour of the port. This is, the sequence in which the operations are invoked. I point this because port is not a classifier and I am not too sure if it can be described with behaviour. <STRONG>-> We do not use port, because it cannot contain behavioural specification</STRONG></EM></P>
<P><EM>- why are we using provided and required interfaces asociation, if we can model that with the serviceInterfaces. In fact in rational <STRONG>-> they are derived asociations they are calculated from the realized and used interfaces of the classes that are used as types of the Requests</STRONG></EM></P>
<P><EM>- should we add something in the description to reflect that the way in which those properties (provided and required) are derived are almost the same ones used for ports and interfaces in UML. In this case I supose that if the type is an interface that will be required, and if the type is a ServiceInterfaces the interfases realised will be required and the interfaces uded will be provided.</EM></P>
<P><EM>- why are we redefining the type to protocol?</EM></P>
<H2>Examples:</H2>
<P><EM></EM> </P>
<H2>Metamodel:</H2>
<P><EM></EM> </P>
<H2>Profile:</H2></BODY></HTML>
redefines type
<HTML><HEAD>
<META content="MSHTML 6.00.2900.2180" name=GENERATOR></HEAD>
<BODY>
<H1>Service</H1>
<H2>Summary:</H2>
<P>A ConnectableElement through which a participant receives and provides all the information it needs to complete its services.</P>
<H2>Description:</H2>
<P>The objective of the Service element is to make it possible to distinguish the main service or services of the Participant and those who are required in order to be able to provide the main services. For example a Purchasing company main service is the PurcheaseService, but in order to provide that service it may require other external services such as Invoicing, Scheduling or Shipping services <EM>(Fig Participant.Example.09.BehaviourOperation)</EM>.</P>
<H2>Semantics:</H2>
<P>A Service inherits from ConnectableElement. It is a ConnectableElement that can provide and request operations to external entities. From a conceptual point of view it identifies the interfaces that constitute the objective of the Participant.</P>
<P>More concretely, if the type of the Service is an Interface, the Participant must be able to provide that interface. In that case the Interface will be provided by the ConnectableElement. If the type of the Service is a ServiceInterface, it means that the Interfaces realized by the ServiceInterface will be provided by the ConnectableElement, and the Interfaces used by the ServiceInterface will be required by the ConnectableElement. </P>
<H2>Semantic Variation Points:</H2>
<P>No semanticVariation Points.</P>
<H2>Issues:</H2>
<P><EM>- similar to those from Request</EM></P><EM>
<P><EM>- should we add something in the description to reflect that the way in which those properties (provided and required) are derived are the same ones used for ports and interfaces in UML</EM></P></EM>
<H2>Examples:</H2>
<P><EM></EM> </P>
<H2>Metamodel:</H2>
<P><EM></EM> </P>
<H2>Profile:</H2>
<P> </P></BODY></HTML>
redefines type
<HTML><HEAD>
<META content="MSHTML 6.00.2900.2180" name=GENERATOR></HEAD>
<BODY>
<H1>ServiceContract</H1>
<H2>Summary:</H2>
<P>A formalization of a collaboration pattern among different service roles. </P>
<H2>Description:</H2>
<P>ServiceContracts are used to specify interaction patterns based on services. They specify the operations involved in the interaction and the sequence of invocation of those operations.</P>
<P>Participants and ConnectableElements can be binded to the different roles of the ServiceContracts. These bindings imply the capability of the Participant or the ConnectableElemenyt to fulfill that role.</P>
<H2>Semantics:</H2>
<P>As a UML Collaboration the ServiceContract purpose is to describe the interaction among a set of roles. As a UML Collaboration the ServiceContract can also be used to realize UseCases that capture contract requirements <EM>(R 6.5.5.1.c)(Fig 04.UseCaseRealzation)</EM>.</P>
<P>The role types in a ServiceContract are expected to be Interfaces, ServiceInterfaces, ConnectableElements or Participants <EM>(Fig 03.RolesTypes)</EM>.</P>
<P>A ServiceContract can also nested in other ServiceContracts. This means that the realisation of the upper level ServiceContract forces the realisation of the nested ServiceContracts.</P>
<P>Where the a ServiceInterfaces, ConnectableElement or Participant has a behaviour and is also used as a type in a ServiceContract, the behaviour must comply with the ServiceContract. However, common practice would be to specify a behaviour in the ServiceContract or ServiceInterface not both.</P>
<P>(R6.5.5.1.f) UML Connectors can be used to indicate possible interactions between roles.</P>
<H2>Semantic Variation Points:</H2>
<P>No Semantic variation Points.</P>
<H2>Issues:</H2>
<P><EM>- Service type must be only an interface? or we can use a Participant specification as a type of role? R6.5.5.1.e</EM></P>
<P><EM>- isStrict I think that it could be better to put that information on the role binding</EM></P>
<H2>Examples:</H2>
<H2><BR>Metamodel:</H2>
<H2><BR>Profile:</H2></BODY></HTML>
<HTML><HEAD>
<META content="MSHTML 6.00.2900.2180" name=GENERATOR></HEAD>
<BODY>
<H1>ConnectableElement:</H1>
<H2>Summary:</H2>
<P>Requests and Services are both ConnectableElements from which information is exchanged with other external entities. The ConnectableElements are not always mandatory and it is possible to specify optional ConnectableElements using the connectorRequired attribute.</P>
<H2>Description:</H2>
<P>Participants can include one or more ConnectableElements to identify service interaction points. The places from which the services are exchanges can be Services or Requests. Services are ConnectableElements that describe the services provided by the Participant, while Requests are ConnectableElements that describe the services that the Participant must consume in order to be able to provide their Services.</P>
<P><EM>(Attr connectorRequired</EM> <EM>)</EM> ConnectableElement provide to Services and Requests with the connectorRequired attribute to indicate whether a connector is required on this connection point. This enable the designer to specify optional services and requests that are not critical for the participant. </P>
<P><EM>(Attr isUsage)</EM> ConnectableElement also provides the isUsage attribute that allows to further distinguish between Services and Request. The default value for this attribute is flase, but for Request the default value for these elements is switched to true. </P>
<H2>Semantics:</H2>
<P><EM>(Attr connectorRequired)</EM> When a ConnectableElement, a Service or a request, has the attribute connectorRequired is set to true (the default value) this implies that there must be at least one connector to that ConnectableElement. This means that if the value is true the Service must be consumed or the requestmust be satisfied. </P>
<P>On the other hand, when the value of connectorRequired is set to false this implies that the Participant is able to work without that Service or request. This may have some implication on the service quality that the Participant should be able to manage. </P>
<P><EM>(Attr isUsage)</EM> When the value of the isUsage (Requests) attribute of a ConnectableElement is set to true it means that the operation provided by the ServiceInterfaces are used and the Interfaces requested by the service interfaces are provided. If the value is false, it means that the provided by the ServiceInterfaces are provided and the Interfaces requested by the service interfaces are requested. <EM> </EM></P>
<P><EM>(ServiceInterface) (R 6.5.15)(01.OptionalServiceSpecifications)</EM> The ConnectableElement inherits from UML TypedElement, therefore it has a type attribute. The type of the ConnectableElement determines the capabilities to be provided or requested through it. But the assignment of the type is optional. Therefore, if it is not assigned it means that the specification of the Service or Request may include or not the specification of the interfaces, operations and behaviours to by provided through the ConnectableElement.</P>
<P><EM>(Interface/ServiceInterface) </EM>A ConnectableElement can be typed with interfaces. It is possible to use regular UML Interfaces or ServiceInterfaces defined in this metamodel. If UML Interfaces are used, it implies that the Participant that owns the ConnectableElement requires that capabilities from external entities, or provides capabilities to external entities. If ServiceInterfaces are used, it means that it will be possible to associate to that ConnectableElement one or more required and provided Interfaces between the provider and the consumer. The sequence of usage of operations of the different interfaces can be described by the ServiceInterface.</P>
<P><EM>(Participant)</EM> When a ConnectableElement (Service or request) is attached to a Participant this means that the Participant is able to provide and process all the interface or the ServiceInterface associated to the ConnectableElement type. It also means that the Participant is able to cope with the roles of the Contracts to which the ConnectableElement is associated through a Role Binding <EM>(02.RoleBindingContract)</EM>.</P>
<H2>Semantic Variation Points:</H2>
<P>No semantic variation points are defined</P>
<H2>Issues:</H2>
<P><EM>- Should we add a constraint to restirct the containment of ConnectableElements to Participants?</EM></P>
<P><EM>-Should we add another constraint to restrict the types to Interfaces (and ServiceInterfaces through inheritance)?</EM></P>
<P><EM>- In the profile if we say that connectable element extends UML ConnectableElement that implies that we could be able to stereotype any ConnectableElement as a requistion or services. This includes not only ports, but properties, etc. Should we avoid this situation?.</EM></P>
<P><EM>- Request and services, both, redefine the type as protocol. maybe it will be more polite to redefine it from the ConnectableElement </EM></P>
<P><EM>-Why we inherit from ConnectableElement and not just from port?</EM></P>
<H2>Examples:</H2>
<P><EM></EM> </P>
<H2>Metamodel:</H2>
<P><EM></EM> </P>
<H2>Profile:</H2></BODY></HTML>
<HTML><HEAD>
<META content="MSHTML 6.00.2900.2180" name=GENERATOR></HEAD>
<BODY>
<H1>ServiceArchitecture</H1>
<H2>Summary:</H2>
<P>A ServiceArchitecture describes how Participants are connected and how they work together. </P>
<H2>Description:</H2>
<P>ServiceArchitectures are used to conceptually relate sets of Participants that work together providing and consuming services. ServiceArchitectures can be used to identify the Participants that work together with a common propouse and the Contracts that rule their interactions. ServiceArchitectures can be also use to group all the Participants that belong to a given domain or all the participants that belong to the same organisation.</P>
<H2>Semantics:</H2>
<P>The SeviceArchitecture is a kind of UML Collaboration and Class, as such, it can be further described with roles, parts and connectors. As a Collaboration it can be latterly used as CollaborationUse inside other architectures, to create grater or extended architectures over the existing ones. </P>
<P>ServiceArchitecture Inherits the isStrict attribute form the Collaboration, when the isStrict is false it means that is not mandatory to fulfill all the roles and behaviours specified by the ServiceArchitecture.</P>
<P>The Participants that colaborate in a service architecture are linked using Parts. The type of the Part Element identifies the Participant that the Part represents. It is also possible to include Contracts instances in the ServiceArchitecture. When a Contract is included in the ServiceArchitecture and it is related to a Participant, that implies that the Participant fullfils that Contract <EM>(01.Participants)</EM>.</P>
<P>Contracts inside the ServiceArchitectures can be linked to Participants or to the ConnectableElements (Services and Request) of the Participants. When a contract is linked to a ConnectableElements it means that the Participant fullfil that contract through that ConnectableElement <EM>(04.ContractsConnectableElement)</EM>.</P>
<H2>Semantic Variation Points:</H2>
<P>No semanticVariation Points.</P>
<H2>Issues:</H2>
<P><EM>- With the profile if we use a component, it is possible to include ConnectableElements (Requisitions and Services Fig 05.ParticipantsComponent) if we use Collaborations (01.ParticipantsCollaboration) that is not possible. If both cases, it is possible to include behaviural descriptions. If we use Component then we cannot use collaboration uses.</EM></P>
<P><EM>- It is absolutelly necessary to force the existance of a compatible port (ConnectableElement) compliant with the serviceContract.</EM></P>
<P><EM>- if the isStrict attribute tries to provide a response to the R5.6.2 I will prefer to indicate that in the role binding rather than in the Collaboration or the collaboration use. The contract is the contract, is the entitie wo can supoort it in a strict or loose way. </EM></P>
<H2>Examples:</H2>
<H2><BR>Metamodel:</H2>
<H2><BR>Profile:<BR></H2>
<P><EM></EM> </P>
<P> </P>
<P> </P></BODY></HTML>
<HTML><HEAD>
<META content="MSHTML 6.00.2900.2180" name=GENERATOR></HEAD>
<BODY>
<H1>ServiceInterface</H1>
<H2>Summary:</H2>
<P>Defines the interface to a Service or Request. The ServiceInterface describe the operations used between a serviceProvide and a service Consumer. </P>
<H2>Description:</H2>
<P>ServiceInterface are used to specify the operations involved in a Service interaction. It can also be used to specify the order in which those operations are executed. ServiceInterfaces are used as a type of a Service or Request. A ServiceInterface can require the provision and requisition of operations, therefore a ServiceInterface can imply the implementation and usage of one or more regular UML Interfaces between the service provider and the service consumer.</P>
<H2>Semantics:</H2>
<P>As a UML Class the ServiceInterfaces can realise and use other interfaces, this allows to represent complex services that require the bidirectional exchange of information between the provider and the consumer. The ServiceInterfaces are not intended to implement the behaviour and the operations they define. ServiceInterfaces are used for specification purposes, the realisation of the operations and the behaviour is implemented by the concrete Participants.</P>
<P>ServiceInterfaces do not directly contain operations. The operations provided by the ServiceInterface are described in the operations of the realized interfaces. While the consumed interfaces are described in the operations of the used interfaces <EM>(Fig 01.Operation) (R 6.5.7.1.b)</EM>. Using UML mechanisms operations can be further described with pre and post conditions, parameters and exceptions <EM>(R 6.5.7.1.c)(R 6.5.7.1.d)</EM>.</P>
<P>ServiceInterfaces can contain behavioural descriptions to describe the way in which the different provided and required operations are executed to fulfill the objectives of the service <EM>(R 6.5.7.1.f) (Fig 02.Behaviour)</EM>.</P>
<H2>Semantic Variation Points:</H2>
<P>No Semantic variation Points.</P>
<H2>Issues:</H2>
<P><EM>- R 6.5.7.1. c I do not see the way to define exceptions <STRONG>-> there is one way operations can point to one or more RaisedExceptions. In RSM this is achived throug the UML Properties of the operation.</STRONG></EM></P>
<H2>Examples:</H2>
<H2><BR>Metamodel:</H2>
<H2><BR>Profile:</H2></BODY></HTML>
subsets clientDependency
subsets ownedElement
<HTML><HEAD>
<META content="MSHTML 6.00.2900.2180" name=GENERATOR></HEAD>
<BODY>
<H1>Collaboration</H1>
<H2>Summary:</H2>
<P>This is an auxiliary element to extend the UML collaboration with the isStrictAttribute. This element is latterly extended by the ServiceContract and the ServiceArchitecture which are described in more detail. .</P>
<H2>Description:</H2>
<P>No.</P>
<H2>Semantics:</H2>
<P>No .</P>
<H2>Semantic Variation Points:</H2>
<P>No.</P>
<H2>Issues:</H2>
<P><EM>- Is this element really needed?</EM></P>
<P><EM>- are we going tu use it as an element of the profile?</EM></P>
<P><EM>- the Strick would be better used as an extension of the conectors used between the parts and roles and the collaborations?</EM></P>
<H2>Examples:</H2>
<P>No.</P>
<H2>Metamodel:</H2>
<P><EM></EM> </P>
<H2>Profile:</H2></BODY></HTML>
<HTML><HEAD>
<META content="MSHTML 6.00.2900.2180" name=GENERATOR></HEAD>
<BODY>
<H1>CollaborationUse</H1>
<H2>Summary:</H2>
<P>CollaborationUse are used to represent fullfilment of ServiceContracts and ServiceArchitectures within structuredClassifiers. </P>
<H2>Description:</H2>
<P>The objective of a CollaborationUse is to show how a Collaboration (ServiceContracts and ServiceArchitectures) is fullfiled by the different inner parts of a structuredClassifiers. Particularly they are used within .ServiceContracts, ServiceArchitectures, Participants and ServiceInterfaces and are roleBinded to ConnectableElements (services and Request), Interfaces and Participants.</P>
<P>They can be used to show the roles that the different ConnectableElements of a Participant must comply with. They can also be used to show how ServiceContracts are build on top of other ServiceContracts. They can also be use to show the ServiceContracts implemented in a ServiceArchitecture.</P>
<H2>Semantics:</H2>
<P>When we link an element with a CollaborationUse (representing a ServiceContract or ServiceArchitecture) this implies that the linked element must satisfy the specification asociated with the CollaborationUse. This can imply to implement operations, interfaces, and behaviours.</P>
<H2>Semantic Variation Points:</H2>
<P>No..</P>
<H2>Issues:</H2>
<P><EM>- Would it be reasonable to include an element (or rename this one) called fulfillment to the metamodel. </EM></P>
<H2>Examples:</H2>
<P><EM></EM> </P>
<H2>Metamodel:</H2>
<P><EM></EM> </P>
<H2>Profile:</H2></BODY></HTML>