The architecture level contains the concepts service provider, service user, Fleksit service, Fleksit basis service, and Fleksit business service, as depicted in Figure 6. A service provider represents a component that offers a set of Fleksit services. A service user is a client of a service provider (i.e., uses one or more of its Fleksit services ,which are interfaces).
Stereotype Metamodel Base Tagged Values Description Constraints
Service owner Actor The legal owner of a Fleksit service.
Service customer Actor The legal user/buyer of a Fleksit service.
Maintainer Actor The legal authority for maintenance, installation, etc., of a service.
Service contract Document The contract established between a service owner and a service customer.
Business agreement
Document The high-level
business agreement between the business parties.
SLA Document The service level
agreement.
Service Use Case The service in question.
Figure 6: Architecture package metamodel
Fleksit Business Service FleksitService Fleksit Service Service User Service Provider 1..n +provides 1..n 1..n +uses_services 1..n
A Generic Framework for Defining Domain-Specific Models 31
Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written The stereotypes for the architecture package are depicted in Figure 7. Service provider and service user are stereotypes of the UML subsystem. Fleksit service (and its subtypes) are stereotypes of the UML interface.
The profile defines the reference architecture of the Fleksit platform. Part of the architecture includes the component interfaces, identified in this reference architecture as a Fleksit service and Fleksit entity (aka. entity). A Fleksit service represents the interface of an architecture component. Each service provides a set of entities, which represent the information flowing though the interface. Figure 8 shows the metamodel concepts.
Figure 9 shows the model profile for services and entities and its base class relation. A Fleksit service is stereotyped as an interface. A Fleksit entity is stereotyped as a class. Figure 7: Architecture package profile
Service Provider <<stereotype>> Service User <<stereotype>> Fleksit Service <<stereotype>> Fleksit BasisService <<stereotype>>
Fleksit Business Service <<stereotype>> Interface (from core) <<metaclass>> <<baseClass>> Subsystem <<metaclass>> <<baseClass>> <<baseClass>>
Figure 8: Architectural services and entities
Fleksit entity Fleksit Service 0..n 0..n +provides 0..n +provided_by 0..n
Figure 9: Interface model package profile
Fleksit service <<stereotype>> Fleksit entity <<stereotype>> class (from core) <<metaclass>> <<baseClass>> interface (from core) <<metaclass>> <<baseClass>>
32 Solberg, Oldevik & Jensvoll
Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
Figure 10 illustrates the use of the profile in a concrete model. The model shows a <<Fleksit service>> named “Product Manager” that manages a set of “Product” and “Customer” <<entities>>.
An example of a platform-specific profile is the standardized UML profile for EJB. This will not be shown here, but its specification can be found at Java Community Process.
Patterns
Patterns represent a special kind of existing model that describes a recurring problem and suggest a general solution to that problem. The tailoring framework is used to define patterns and categorize them according the actual model architecture of the chosen methodology. For the xx methodology in Figure 1, there might be business model patterns, architecture model patterns, and platform-specific model patterns. A pattern is employed by instantiating it (as a template) into a concrete model. The concrete model defines who or what is fulfilling the responsibilities that are defined by the roles in the pattern.
The tailoring framework includes a framework for pattern definition and use. This pattern framework includes some special notation (defined in an UML profile) and a template for pattern description.
Stereotype Metamodel base Tagged Values Description Constraints
Fleksit service interface
Interface A service access
interface; corresponds to a Fleksit service from the architecture profile. self.allOppositeAssociationE nds -> forAll (a | a.type.oclIsTypeOf (Fleksit service) or a.type.oclIsTypeOf (Fleksti entity))
Fleksit entity Class Represents
information flowing in a service. self.allOppositeAssociationE nds -> forAll(a | a.type.oclIsTypeOf(Entity)) ProductManager <<Fleksit service>> + getProducts() + getCustomers() Address <<entity>> ProductCategory <<entity>> Customer <<entity>> 0..n 0..n +customers 1..n 1..n +address Product <<entity>> 0..n 0..n 1 0..n 1 0..n 0..n 0..n +products_for_customer +products
Figure 10: Profile (stereotype) usage
A Generic Framework for Defining Domain-Specific Models 33
Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written The pattern structure technique of UML collaboration is used as a basis to define the pattern. The pattern structure technique is used for viewing the collaboration as a single entity from the outside. The collaboration details are further defined using a UML activity diagram or UML sequence diagram. A simple example describing a pattern for a naming service and the usage of the pattern is shown in Figure 11.
A UML collaboration describes the collaboration of roles. A role is a placeholder for a set of objects that can fulfil the responsibilities of that role. Roles can be specified in two ways in UML: instance level and specification level. Instance level role collabo- rations are described in terms of collaboration diagrams with objects, links, and message stimuli. Specification level collaborations are described by “ClassifiersRoles” and “AssociationRoles”.
UML has defined a naming convention denoting roles, which is a simple way to indicate a role. The general syntax is:
ObjectName ‘/’ ClassifierRoleName ‘:’ ClassifierName [‘,’ ClassifierName]* This convention can be used on both instance-level and specification-level col- laborations.
A collaboration can be considered a set of roles collaborating to fulfill a mission as defined by the unified responsibilities of the roles in the collaboration. Collaborations as a concept have been proven useful in several recognized methodology approaches. Catalysis (D’Souza, 1998) uses collaborations and collaboration refinements for analy- sis, design, and reuse purposes. OORam (Reensaug, 1996) uses role models to describe collaborations of roles and synthesis to refine and reuse existing models. Lately, the UML community also embraces this view of collaborations.
The top left of Figure 11 show the pattern structure in terms of roles collaborating to fulfil a mission defined by the unified responsibilities of the roles in the collaboration. The naming pattern defined includes three roles: “Name Binder”, “Name Client,” and “Naming Handler”.
A collaboration is modelled as a use case stereotyped with <<collaboration>>. The roles are modelled as UML actors with role names. These roles can be either external or internal to the pattern. External roles are parameterised when the pattern is used. The worker stereotype defined in RUP is used to denote internal actors. The “Naming Handler” is an internal role in the example. The semantics of the collaboration “use case” are the same as a UML collaboration pattern structure (a use case realization).
The sequence diagram at the top right of Figure 11 defines the behavior of the pattern by specifying interactions between roles. Certain conventions for describing behavior in a UML sequence diagram are defined when describing a pattern using the following framework:
•
Messages sent to a role are described in the standard UML manner. These may or may not be messages that exist as a part of that role’s protocol. Using ‘//’ as prefix for a method denotes that this method is not explicitly located in the interface (i.e., it may be an analysis operation only or a reference to existing behavior pattern).•
Return values are always specified explicitly with a special message-sending convention (i.e., the message name is the value of the return and it is packed in curly braces, e.g., {IObjectType}).34 Solberg, Oldevik & Jensvoll
Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
•
Errors or exceptions are specified to the extent considered necessary. The conven- tion is the same as for method returns, except that an exclamation mark (!) is used to indicate the nature of an exception (e.g.,{!IOException}).In order to use a pattern, the desired external roles of the pattern must be instantiated. This is done by using a specialized “binding” relationship that binds the pattern collaboration source to the roles that instantiate the designated roles of the pattern. The role parameters are bound by the role/name specified on the binding relation (e.g., ‘/NameClient’). The lower left area of Figure 11 shows how a pattern can be instantiated by binding the roles from the pattern. There are no limits as to how many roles can be bound to other roles or actors.
Figure 11: Pattern description and usage
/NameClient
/NameBinder
Naming (from Use Case View)
<<pattern>>
/NamingHandler Naming
<<collaboration>>lookupby name service bind name
to service
: /NameBinder : /NameHandler : /NameClient
bind("servicename", "service")
updateRegistry {Service}
{Failed to register}
rebind("servicename", "service")
updateRegistry {Service} {Failed to register} lookup("servicename") searchRegistry {Service} {!ServiceNotRegisteredException} CustomerSearcherr CustomerSearchClient CustomerHandling search for a customer obtain customer info Naming <<collaboration>> (from Naming) /NameBinder <<bind>> /NameClient <<bind>> CustomerProvider edit/add customer /NameClient <<bind>> CustomerSearche r : /NameBinder INameService : /NameHandler CustomerProvider : /NameClient CustomerSearchClient : /NameClient rebind("customerSearch", CS) updateRegistry lookup("customerSearch") lookup("customerSearch")
Pattern description in UML
A Generic Framework for Defining Domain-Specific Models 35
Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written The sequence diagram at the lower right in Figure 11 shows an example of synthesizing a pattern onto a specific architecture.
The framework provides a template for the pattern description as shown below:
Name
Names the pattern after the solution it proposes. The pattern name can be composed of verb phrases that stress the action implied or can use descriptive nouns.
Problem description
Provides a thumbnail description of the problem that the pattern is solving (text description).
Parameterised structure
Identifies the roles participating in the collaboration and the collaboration symbol (the use case view) (UML use case diagram).
Behavior
Describes the behavioral details of the collaboration (UML activity or sequence diagram). Example
Provides an example of usage.
Existing Models
Existing models represent already defined, concrete models that can be reused by package importing and referencing. In the same way as used for the UML profiles and patterns, the tailoring framework prescribes that the existing models should be catego- rized and structured according to the model architecture of the chosen general-purpose methodology. An example of typical usage of an existing model is to reuse an existing interface by inheritance or reference.
An existing model is reused in terms of package import, where the namespace defined by the package becomes available. All public artifacts (use cases, actors, interfaces, classes, etc.) become available to the import package. Alternatively, elements from an existing model can be used simply by scoped naming or UML pathnames (e.g., nnCore::PervasiveServices:: NamingService::INaming, which refers to the INaming inter- face contained in the package structure implied).
The general mechanism for reuse of a either a pattern or standard model is by import of the package that defines the model. Package import makes the model elements defined in that package available by model elements, meaning interfaces, classes, etc. In principle, we can then reference interfaces, etc., from that package.
Package import is straightforward in UML. It is done with the <<import>> depen- dency stereotype between packages.