Applying the SoaML profile using composite structure diagram of UMLstructure diagram of UML

Composite structure diagram is a type of static structure diagram that shows the internal structure of a classifier by using parts, ports, and connectors and the collaborations that this structure makes possible. The term

"structure" for this type of diagrams is defined in UML as a composition of interconnected elements, representing run-time instances collaborating over communications links to achieve some common objectives.

A structured classifier defines the implementation of a classifier and can include a class, a component, or a deployment node. You can use the composite structure diagram to show the internal details of a classifier and to describe the objects and roles that work together to perform the behavior of the containing classifier.

A composite structure diagram is similar to a class diagram, but it depicts individual parts instead of whole classes. Before you can define the internal structure of a classifier, you must either show its structure compartment or open a composite structure diagram. You can then model the parts that represent the instances that the containing classifier owns. You can add connectors to link two or more parts in an association or dependency relationship.

In composite structure diagrams, ports define the interaction point between a classifier and its environment or between a classifier and its internal parts. You can use a port to specify the services that a classifier provides to and requires from its environment.

You can also model collaborations and collaboration uses in composite structure diagrams. A collaboration describes the roles and attributes that define a specific behavior of the classifier. A collaboration use represents one particular use of the collaboration to explain the relationships between the properties of a classifier. To identify the roles of the parts in the collaboration use, you attach a collaboration use to a collaboration and then add the collaboration use to a composite structure diagram.

Internal structure diagram shows internal structure of a classifier—a decomposition of that classifier into its properties, parts and relationships. Figure Figure 7.4, ―Shipping service with two customers‖ shows an example use of internal structure diagram. It utilizes the «Participant» stereotype defined in the SoaML profile and shows the various participants of an OrderingSubsystem as well as the interfaces they required or provided in accomplishing services. Note that the way how participants interact is not modeled in service participant diagram. This diagram focuses on the person, organization, system or anyone who take part in a services architecture.

Figure 7.4. Shipping service with two customers

SoaML supports both a contract and an interface-based approach to SOA. They differ in the way services are specified.

The interface-based approach involves the use of simple interfaces and service interface. Simple interface focuses mainly on one-way service delivery that requires no protocol between parties. Service interface allows for bi-directional services. Provider and consumer work together to complete a service.

Service interface diagram is a type of SoaML diagram specialized for the definition and specification of both simple interface and service interface. As an example, Figure Figure 7.5, ― ShippingService service interface‖

applies the internal structure diagram to describe the ShippingService interface.

Figure 7.5.

service interface

The service contract approach defines the contract that specify how providers and consumers work together to achieve a goal, through the use of service. The service contract represents an agreement between parties for how the service is to be provided and consumed. Such agreement includes the interfaces, choreography and other terms and conditions.

Such a service contract diagram is designed for the specification of service contract by applying the Collaboration use diagram (which is also part of the composite structures diagram of the UML).

The behavior of the system is the functionality that the system under design will implement or which is already implemented by some existing system. Objects in a system typically cooperate with each other to produce the behavior of a system. A behavior of a collaboration will eventually be exhibited by a set of cooperating instances (specified by classifiers) that communicate with each other by sending signals or invoking operations.

However, to understand the mechanisms used in a design, it may be important to describe only those aspects of these classifiers and their interactions that are involved in accomplishing a task or a related set of tasks, projected from these classifiers. Collaborations allow us to describe only the relevant aspects of the cooperation of a set of instances by identifying the specific roles that the instances will play. Interfaces allow the externally observable properties of an instance to be specified without determining the classifier that will eventually be used to specify this instance. Consequentially, the roles in a collaboration will often be typed by interfaces and will then prescribe properties that the participating instances must exhibit, but will not determine what class will specify the participating instances. Collaboration use represents one particular use (occurrence) or application of the pattern described by a collaboration to a specific situation involving specific classes or instances playing the

roles of the collaboration. A collaboration use shows how the pattern described by a collaboration is applied in a given context, by binding specific entities from that context to the roles of the collaboration.

In this figure, Purchasing Service is an example of a collaboration name, buyer and seller are examples of roles of the corresponding role types Buyer and Seller (which are classifiers).

Figure 7.6. Service interfaces of a compound service

Message Diagram of SoaML is dedicated to model SoaML Message Types as well as their internals using links to classes representing the data model. This diagram covers basic cases of MessageType composition modeling.

The data models should be modeled with UML class diagrams.

Figure 7.7. MessageTypes in purchase order processing

References

Books

[HULL2010] Elizabeth Hull, Ken Jackson, and Jeremy Dick. Requirements Engineering. Springer. 2010. 3.

978-1849964043. 217.

[MELLOR2002] Stephen J. Mellor and Marc J. Balcer. Executable UML. A Foundatiuon for Model-Driven Architecture. Addison-Wesley. 2002. 1. 9780201748048. 416.

[SOMMERVILLE2010] Ian Sommerville. Software Engineering. Addison-Wesley. 2010. 9. 978-0137035151.

792.

[FOWLER2003] Martin Fowler. UML Distilled. A Brief Guide to the Standard Object Modeling Language.

Addison-Wesley. 2003. 3. 978-0321193681. 208.

[FOWLER1996] Martin Fowler. Analysis Patterns. Reusable Object Models. Addison-Wesley. 1996. 1. 978-0201895421. 384.

[FOWLER2002] Martin Fowler. Patterns of Enterprise Application Architecture. Addison-Wesley. 2002. 1.

978-0321127426. 560.

[ROSENBERG2007] Doug Rosenberg. Matt Stephens. Use Case Driven Object Modeling with UML. Theory and Practice. Apress. 2007. 1. 978-1590597743. 438.

[AMBLER2005] Scott W. Ambler. The Elements of UML 2.0 Style. Cambridge University Press. 2005. 1. 978-0521616782. 200.

[AMBLER2004] Scott W. Ambler. The Object Primer. Agile Model-Driven Development with UML 2.0.

Cambridge University Press. 2004. 3. 978-0521540186. 572.

[AMIGOS2005] Grady Booch, James Rumbaugh, and Ivar Jacobson. The Unified Modeling Language User Guide. 2005. 2. 978-0321267979. 496.

[GOMAA2011] Hassan Gomaa. Software Modeling and Design. UML, Use Cases, Patterns, and Software Architectures. Cambridge University Press. 2011. 1. 978-0521764148. 576.

[SWEBOK2014] IEEE Computer Society. Pierre Bourque. Richard E. Fairly. SWEBOK v3.0. Guide to the Software Engineering Body of Knowledge. IEEE Computer Society Press. 2014. 3. 978-0769551661.

346.

[IEEE830:1998] IEEE Computer Society. IEEE 830: IEEE Recommended Practice for Software Requirements Specifications. IEEE Computer Society Press. 1998. 978-0738103327. 40.

[IEEE1016:2009] IEEE Computer Society. IEEE Standard for Information Technology—Systems Design—

Software Design Descriptions. IEEE 1016-2009. IEEE Computer Society Press. 2009. 978-0738159256. 35.

[IEEE29148:2011] IEEE Computer Society. IEEE Systems and software engineering—Life cycle processes—

Requirements engineering. ISO/IEC/IEEE 29148:2011. IEEE Computer Society Press. 2011. 978-0738165912. 94.

[GONCALVES2013] Antonio Goncalves. Beginning Java EE 7. Apress. 2013. 978-1430246268. 608.

Online sources

[SPARXSYSTEMS] UML 2 Tutorial. Web page .

[OMGUML] Unified Modeling Language (UML) Resource Page . Web page .

[UML2.4.1INFRA] OMG Unified Modeling Language (OMG UML), Infrastructure, Version 2.4.1. PDF .

[UML2.4.1SUPER] OMG Unified Modeling Language (OMG UML), Infrastructure, Version 2.4.1. PDF . [SoaML] Service oriented architecture Modeling Language (SoaML) Resource Page . Web page . [SoaML1.0.1] OMG Service oriented architecture Modeling Language (SoaML), Version 1.0.1. PDF . [UML-DIAGRAMS.ORG] UML-Diagrams.org. Web page .

[SPARXSYSTEMS.COM] SPARXSSTEMS UML2 tutorial. Web page .

[JAVAEE7TUTORIAL] The Java EE 7 Tutorial. Eric Jendrock, Ricardo Cervera-Navarro, Ian Evans, Kim Haase, and William Markito. Web page .