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.
Introduction to Class Diagram
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.
Composite Structure Diagrams
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.
The deployment diagram is an element that will model hardware that is used during the system implementation. It will also be responsible for modeling the components which make up the hardware. The deployment diagram must also deal with the associations that occur among various elements.
The key structures that make up deployment diagrams are nodes, which will be shown visually as cubes. The components of the deployment diagram will also be shown in the form of rectangles, and associations are included as well. The rectangles may also have twin rectangular boxes coming out of one side. It must be noted that components won’t be placed in nodes in UML 2.0.
Instead of placing components in nodes, the artifacts will be placed in nodes in UML 2.0. An artifact can be defined as a file, library, or data that is modified within a project. The artifacts will be responsible for the implementation of component collections. The internal nodes will need to deal with execution environments instead of use hardware. Some examples of these execution environments include operating systems or language interpreters.
The object diagram is an element that showcases a portion of the structure of a system that has been modeled. It is designed to do this at specific times. The object diagram will often be closely related to both attributes and object instances, a well as the links between these instances.
A correlated group of object diagrams will provide the insight for how a system will evolve over time. When compared to class diagrams, object diagrams are much more concrete. They are frequently used to provide examples, and they may also be used to to test various cases for class diagrams. An object diagram is best used in situations where the user only needs to view aspects of the model which are the most important. Another element which is closely related to object diagrams is the InstanceSpecification.
The InstanceSpecification is used to symbolize the objects and links of an object diagram. It can show the classifier of the object, and it can also show the instance name as well. This will be done by using slots, and one slot will be used to represent one feature.
The package diagram is an element which will define how the system is broken up into groupings. It will do this by showing the dependencies that exist within these groups. Because the package is commonly thought of as a directory, the package diagram will act as a hierarchy breakdown of the system.
The package will be organized in a way that will allow it to max out the inner coherence of the individual package. In addition to this, it will also reduce the outer coupling for the packages. Once all these guidelines are set into place, the packages will be ideal for management.