UML 2.0 is comprised of a total of 13 diagrams. If you wish to understand these diagrams, they should be organized based on a hierarchy. For UML, a diagram is an element which must define which things should be modeled in a system.
In this article, I will go over various diagrams in detail to explain what they are, and how they are useful in the Unified Modeling Language. The first thing I would like to start off with is the class diagram. The class diagram is a static structure diagram that will showcase the system structure. It will do this by demonstrating the classes of the system, as well as its attributes and relationships with the other classes.
In a software application, the class will be represented by a box. This box will have the name of the class inside it. The class will be used to symbolize either a domain, or an element that is not related to software. An additional compartment will be made available below the name of the class, and this can be used to show various attribute which are related to that class. These attributes are formally known as properties. At the very minimum, each property will show its name, and the developer is also given the option of including its initial value, type, and additional properties. The operations of the class may appear in another compartment, and they are used to denote the methods of the class.
Each operation must have at least a name, and it may also have parameters and a return type, but these are both optional. There are additional compartments that may be defined in terms of requirements or constraints. The operations may be marked by a number of different symbols, and each symbol is used to mean something different. For example the "+" means "public," and the "#" symbol means "protected." The "-" is used to mean private, and the "~" is used to mean package. The class diagram will show the details of how various classes are connected together, and it will also deal with the relationships that exist among these classes.
Within UML, the component diagram is an element which will show how the software application is broken up into physical components. It will also reveal information about dependencies that may exist within these components. An example of a physical component could be a file, module, or executables. The component diagrams may be used document the architecture of the system, and it can also be used to model this architecture as well. It should also be noted that the component is the only type that is allowed to have instances.
The composite structure diagram is an element which will reveal the inner workings of a class, as well as the collaborations that the structure will make possible. Some of this will include inner parts and ports which will interact together or with instances. It should be noted that the instances of the class may be responsible for interacting with portions of the outside world. Between ports, it will act as a connector. The composite structure itself is a set of elements that are intertwined with one another. During the runtime, these elements will work together to achieve a specific goal. Every connected element will have a specific role to play during this collaboration.
In UML 2.0, there are a number of elements which make up the composite structure diagram. These elements are the collaborations, the structured classifiers, connectors, parts, and ports. The structured classifier will symbolize a class, and its function may be described in the way it interacts with other elements. The part will symbolize a role that is processed during the runtime. While the part may only be responsible for naming the role, it may also be responsible for naming a superclass.
As the name suggests, the port is used as a point of interaction. It can be used to connect to structured classifiers in a number of different ways. The connector is an element that will bring multiple elements together, and it can allow them to work together during the runtime. The collaboration will be responsible for holding the roles that instances must play.