Composite structure diagram

Last updated August 25, 2024

Composite structure diagram^[1] in the Unified Modeling Language (UML) is a type of static structure diagram that shows the internal structure of a class and the collaborations that this structure makes possible.

This diagram can include internal parts, ports through which the parts interact with each other or through which instances of the class interact with the parts and with the outside world, and connectors between parts or ports. A composite structure is a set of interconnected elements that collaborate at runtime to achieve some purpose. Each element has some defined role in the collaboration.

Concepts

The key composite structure entities identified in the UML 2.0 specification are structured classifiers, parts, ports, connectors, and collaborations.^[2]

Part : A part represents a role played at runtime by one instance of a classifier or by a collection of instances. The part may only name the role, it may name an abstract superclass, or it may name a specific concrete class. The part can include a multiplicity factor, such as the [0..*] shown for Viewer in the diagram.
Port : A port is an interaction point that can be used to connect structured classifiers with their parts and with the environment. Ports can optionally specify the services they provide and the services they require from other parts of the system. In the diagram, each of the small squares is a port. Each port has a type and is labelled with a name, such as "var", "indVar1", or "view" in the diagram. Ports may contain a multiplicity factor, for example [3].

Ports can either delegate received requests to internal parts, or they can deliver these directly to the behavior of the structured classifier that the port is contained within. Public ports that are visible in the environment are shown straddling the boundary, while protected ports that are not visible in the environment are shown inside the boundary. All the ports in the diagram are public, except for the view port along the right boundary of FibonacciSystem.

Connector : A connector binds two or more entities together, allowing them to interact at runtime. The connector is shown as a line between some combination of parts, ports and structured classifiers. The diagram shows three connectors between ports, and one connector between a structured classifier and a part.
Collaboration : A collaboration is generally more abstract than a structured classifier. It is shown as a dotted oval containing roles that instances can play in the collaboration.
Structured classifier : A StructuredClassifier represents a class, often an abstract class, whose behavior can be completely or partially described through interactions between parts.
Encapsulated classifier : An EncapsulatedClassifier is a type of structured classifier that contains ports. In the diagram below, both FibonacciSystem and Variable are encapsulated classifiers because they both have ports along their boundaries.

Examples

As an example, consider one possible way of modeling production of the Fibonacci sequence.

This UML 2.0 composite structure diagram specifies that instances of the 'FibonacciSystem' class are composed of a number of parts. The topmost of these parts is identified as having the classifier 'FibonacciFunction'. Three of the parts are identified by the role they play within instances of FibonacciSystem - the NMinus2 role, the NMinus1 role, and the N role. The fifth part, identified by its classifier Viewer, includes a multiplicity specification. At runtime there can be 0 or more instances of Viewer or some concrete subclass of Viewer.

At runtime the class instances that implement these three roles must provide the services specified by the IVar interface through their var ports. One such class is Variable, shown on the diagram with a port named var of type Var that realizes the IVar interface.

The port named "view" is a non-public port that can be used by an instance of FibonacciSystem to access the optional instance(s) of Viewer.

Related Research Articles

An object-modeling language is a standardized set of symbols used to model a software system using an object-oriented framework. The symbols can be either informal or formal ranging from predefined graphical templates to formal object models defined by grammars and specifications.

The unified modeling language (UML) is a general-purpose visual modeling language that is intended to provide a standard way to visualize the design of a system.

A stereotype is one of three types of extensibility mechanisms in the Unified Modeling Language (UML), the other two being tags and constraints. They allow designers to extend the vocabulary of UML in order to create new model elements, derived from existing ones, but that have specific properties that are suitable for a particular domain or otherwise specialized usage. The nomenclature is derived from the original meaning of stereotype, used in printing. For example, when modeling a network you might need to have symbols for representing routers and hubs. By using stereotyped nodes you can make these things appear as primitive building blocks.

<span class="mw-page-title-main">Sequence diagram</span> Visualisation of computer system processes

In software engineering, a sequence diagram shows process interactions arranged in time sequence. This diagram depicts the processes and objects involved and the sequence of messages exchanged as needed to carry out the functionality. Sequence diagrams are typically associated with use case realizations in the 4+1 architectural view model of the system under development. Sequence diagrams are sometimes called event diagrams or event scenarios.

In computer science, object composition and object aggregation are closely related ways to combine objects or data types into more complex ones. In conversation the distinction between composition and aggregation is often ignored. Common kinds of compositions are objects used in object-oriented programming, tagged unions, sets, sequences, and various graph structures. Object compositions relate to, but are not the same as, data structures.

<span class="mw-page-title-main">Class diagram</span> Diagram that describes the static structure of a software system

In software engineering, a class diagram in the Unified Modeling Language (UML) is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, operations, and the relationships among objects.

<span class="mw-page-title-main">Business Process Model and Notation</span> Graphical representation for specifying business processes

Business Process Model and Notation (BPMN) is a graphical representation for specifying business processes in a business process model.

A package diagram in the Unified Modeling Language depicts "specializations for Models and for Profiles that organize extensions to UML."

Activity diagrams are graphical representations of workflows of stepwise activities and actions with support for choice, iteration, and concurrency. In the Unified Modeling Language, activity diagrams are intended to model both computational and organizational processes, as well as the data flows intersecting with the related activities. "Object nodes hold data that is input to and output from executable nodes, and moves across object flow edges. Control nodes specify sequencing of executable nodes via control flow edges." In other words, although activity diagrams primarily show the overall control flow, they can also include elements showing the data flow between activities through one or more data stores.

A communication diagram in Unified Modeling Language (UML) 2.5.1 is a simplified version of the UML 1.x collaboration diagram.

Glossary of Unified Modeling Language (UML) terms provides a compilation of terminology used in all versions of UML, along with their definitions. Any notable distinctions that may exist between versions are noted with the individual entry it applies to.

Executable UML is both a software development method and a highly abstract software language. It was described for the first time in 2002 in the book "Executable UML: A Foundation for Model-Driven Architecture". The language "combines a subset of the UML graphical notation with executable semantics and timing rules." The Executable UML method is the successor to the Shlaer–Mellor method.

MagicDraw is a proprietary visual UML, SysML, BPMN, and UPDM modeling tool with team collaboration support.

In object-oriented programming, an object diagram in the Unified Modeling Language (UML) is a diagram that shows a complete or partial view of the structure of a modeled system at a specific time.

In the Unified Modeling Language (UML), a Dependency is "a Relationship that signifies that a single model Element or a set of model Elements requires other model Elements for their specification or implementation." "This means that the complete semantics of the client Element(s) are either semantically or structurally dependent on the definition of the supplier Element(s)." Two or more elements in this relationship are called tuples.

The first version of the Enterprise Collaboration Architecture (ECA) has been published by the Object Management Group (OMG) in 2001. The vision of the (ECA) is to simplify the development of component based and services oriented systems by providing a modeling framework aligned with the model-driven architecture (MDA) of the Object Management Group (OMG).

<span class="mw-page-title-main">Component (UML)</span>

A component in the Unified Modeling Language represents a modular part of a system that encapsulates the state and behavior of a number of classifiers. Its behavior is defined in terms of provided and required interfaces, is self-contained, and substitutable. A number of UML standard stereotypes exist that apply to components.

UML state machine, formerly known as UML statechart, is an extension of the mathematical concept of a finite automaton in computer science applications as expressed in the Unified Modeling Language (UML) notation.

UML is a modeling language used by software developers. UML can be used to develop diagrams and provide users (programmers) with ready-to-use, expressive modeling examples. Some UML tools generate program language code from UML. UML can be used for modeling a system independent of a platform language. UML is a graphical language for visualizing, specifying, constructing, and documenting information about software-intensive systems. UML gives a standard way to write a system model, covering conceptual ideas. With an understanding of modeling, the use and application of UML can make the software development process more efficient.

In Unified Modeling Language (UML) 2.5.1, an Element is "a constituent of a model. As such, it has the capability of owning other Elements."

References

↑ "Composite Structure Diagram". Unified Modeling Language 2.5.1. OMG Document Number formal/2017-12-05. Object Management Group Standards Development Organization (OMG SDO). December 2017. p. 728.
↑ OMG (2008). OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2 Archived 2010-09-23 at the Wayback Machine p.161-192.

External links

General information on UML including the official UML 2.0 specification. See especially the large section on Composite Structures.
The Xholon open-source project maintains a set of links having to do with composite structure.
UML 2 Composite Structure Diagrams

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.

[OMG-1] "Composite Structure Diagram". Unified Modeling Language 2.5.1. OMG Document Number formal/2017-12-05. Object Management Group Standards Development Organization (OMG SDO). December 2017. p. 728.

[OMG_UML_V2.1.2-2] OMG (2008). OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2 Archived 2010-09-23 at the Wayback Machine p.161-192.

[1]

[2]