UML Profile Diagram Examples
Here we provide some examples of UML profile diagrams:
SoaML UML Profile
UML Profile for Service Oriented Architecture is described in Service Oriented Architecture Modeling Language (SoaML) specification. "The goals of SoaML are to support the activities of service modeling and design and to fit into an overall model-driven development approach" [SoaML 1.0 Beta 2]. The SoaML specification contains both a SoaML metamodel and a SoaML UML profile.
The SoaML UML profile supports modeling of service-oriented architectures, including specification of systems of services, specification of individual service interfaces, and specification of service implementations.
A service is defined there as a value delivered to another through a well-defined interface and available to a community (which may be the general public). A service results in work provided to one by another.
SoaML UML Profile - Contracts
Collaboration, Service Contract or Services Architecture represents a pattern of interaction between roles. In SoaML this interaction may be informal and loosly defined as in a requirements sketch. It may also represent formal agreements or requirements that must be fulfilled exactly.
Service description specifies how participants interact to provide or use a service. In SoaML there are three ways to specify a service interaction – a UML Interface, a Service Interface and a Service Contract.
Consumer models the interface provided by the consumer of a service. The consumer of the service receives the results of the service interaction. The consumer will normally be the one that initiates the service interaction.
It looks weird that Consumer and Provider both extend Interface and Class metaclasses. The SoaML explains that Interface is used in the case of a non composite service contract while Class - in the case of a composite service contract.
SoaML UML Profile - Services
Participants are either specific entities or kinds of entities that provide or use services. Participants can represent people, organizations or information system components. Participants may provide any number of services and may consume any number of services. Participants provide or consume services via ports.
Agent is autonomous entity that can adapt to and interact with its environment. Agent can be software agent, hardware agent, firmware agent, robotic agent, human agent, and so on.
Port is the part or feature of a participant that is the interaction point for a service – where it is provided or consumed. A port where a service is offered may be designated as a «Service» port and the port where a service is consumed may be designated as a «Request» port.
Request extends Port to specify a feature of a Participant that represents a service the Participant needs and consumes from other participants. The request is defined by a Service Interface. A request port is a "conjugate" port - the provided and required interfaces of the port type are inverted, creating a port that uses the port type rather than implementing the port type.
Service represents a feature of a Participant that is the offer of a service by one participant to others using well defined terms, conditions and interfaces. A Service designates a Port that defines the connection point through which a Participant offers its capabilities and provides a service to clients.
SoaML UML Profile - Service Data
Message Type defines information exchanged between service consumers and providers. Message Type should generally only be applied to Data Type since it is intended to have no identity. However, SoaML recognizes that many existing models do not clearly distinguish identity, either mixing Class and DataType, or only using Class. Because of this, another odd thing is that SoaML allows Message Type to extend Class as well as Data Type.
Attachment is a part of a Message that is attached to rather than contained in the message.
Java EJB 3.0 UML Profile
Official Metamodel and UML Profile for Java and EJB Specification, Version 1.0 by OMG and JCP [UML Profile for Java and EJB. Version 1.0] is for Java 1.3, EJB 1.1 and most likely UML 1.4, so it could be only of some interest to bookworms.
UML 2.4 specification [UML 2.4 - Superstructure] provides example profile for unspecified version of J2EE/Enterprise Java Beans (EJB) in Annex D.1. That UML sample profile is neither normative (official) nor complete, and is provided only as an illustration.
Here we provide an example of simplified and unofficial UML Profile for EJB 3.0 with support for session, entity, and message-driven Enterprise JavaBeans.
The EJB 3.0 specification defines both stateful and stateless session beans. There are differences in the API between stateful session beans and stateless session beans. The client of a session bean may be a local client, a remote client, or a web service client, depending on the interface provided by the bean and used by the client.
Stateful session bean represents a conversational session with a particular client. Such session objects automatically maintain their conversational state across multiple client-invoked methods.
An entity object represents a fine-grained persistent object. The client of an entity bean may be a local client or the client may be a remote client.
The message-driven bean class must implement the appropriate message listener interface for the messaging type that the message-driven bean supports or specify the message listener interface using the MessageDriven metadata annotation or the messaging-type deployment descriptor element.
The ejb-jar file must contain the deployment descriptor in the format defined in EJB Specification. The deployment descriptor must be stored with the name META-INF/ejb-jar.xml
Simplified example of unofficial Java EJB 3.0 Profile
DICOM UML Profile
A simplified example of DICOM UML Profile for 2009 version of Digital Imaging and Communications in Medicine (DICOM) standard which facilitates interoperability of medical imaging equipment.
A Service Class Specification defines a group of one or more SOP Classes related to a specific function which is to be accomplished by communicating Application Entities. A Service Class Specification also defines rules which allow implementations to state some pre-defined level of conformance to one or more SOP Classes. Applications may conform to SOP Classes as either a Service Class User (SCU) or Service Class Provider (SCP).
Service-Object Pair (SOP) Class is the union of a DIMSE Service Group and one related Information Object Definition (IOD) which completely defines a precise context for communication of operations on such an object or notifications about its state. The SOP Class definition contains the rules and semantics which may restrict the use of the services in the DIMSE Service Group or the Attributes of the IOD.
A DIMSE Service Group specifies one or more operations/notifications which are applicable to an IOD.
Information Object Definition (IOD) is an abstraction of a real information entity (e.g., CT Image, Structured Report, etc.) which is acted upon by one or more DICOM Commands. An IOD does not represent a specific instance of a Real-World Object, but rather a class of Real- World Objects which share the same properties.
A Normalized IOD is an Information Object Definition which generally represents a single entity in the DICOM Model of the Real-World.
A Composite IOD is an Information Object Definition which represents parts of several entities in the DICOM Model of the Real-World. Such an IOD includes Attributes which are not inherent in the Real-World Object that the IOD represents but rather are inherent in related Real-World Objects.
The Attributes of an IOD describe the properties of a Real-World Object Instance. Related Attributes are grouped into Modules which represents a higher level of semantics documented in the Module Specifications.
Simplified example of DICOM 2009 Profile
