This is the next installment in a series of articles about the essential diagrams used within the Unified Modeling Language, or UML. Continuing down the track of UML 2 structure diagrams, this article introduces the component diagram. In UML 1. UML 2 officially changes the essential meaning of the component concept; in UML 2, components are considered autonomous, encapsulated units within a system or subsystem that provide one or more interfaces.
|Published (Last):||25 October 2007|
|PDF File Size:||5.26 Mb|
|ePub File Size:||10.21 Mb|
|Price:||Free* [*Free Regsitration Required]|
This is the next installment in a series of articles about the essential diagrams used within the Unified Modeling Language, or UML. Continuing down the track of UML 2 structure diagrams, this article introduces the component diagram.
In UML 1. UML 2 officially changes the essential meaning of the component concept; in UML 2, components are considered autonomous, encapsulated units within a system or subsystem that provide one or more interfaces. But, unlike UML 1. Note: The physical items that UML1.
An artifact is a physical unit, such as a file, executable, script, database, etc. A single component could be manifested by multiple artifacts, which could be on the same or different nodes, so a single component could indirectly be implemented on multiple nodes. In component-based development CBD , component diagrams offer architects a natural format to begin modeling a solution.
In addition, component diagrams are useful communication tools for various groups. The diagrams can be presented to key project stakeholders and implementation staff. System administrators find component diagrams useful because they get an early view of the logical software components that will be running on their systems.
Although system administrators will not be able to identify the physical machines or the physical executables from the diagram, a component diagram will nevertheless be welcomed because it provides early information about the components and their relationships which allows sys-admins to loosely plan ahead. The component diagram notation set now makes it one of the easiest UML diagrams to draw. Figure 1 shows a simple component diagram using the former UML 1.
As you can see, a component in UML 1. The above UML 1. However, the UML 1. For that reason, UML 2 dramatically enhances the notation set of the component diagram, as we will see throughout the rest of this article.
The UML 2 notation set scales better, and the notation set is also more informative while maintaining its ease of understanding. Consistently deliver high-quality software faster using DevOps Continuous Delivery. Edit your code anywhere with Git repos and issue tracking, deliver continuously with an automated pipeline, get Insights to improve quality, and more.
Drawing a component in UML 2 is now very similar to drawing a class on a class diagram. In fact, in UML 2 a component is merely a specialized version of the class concept. Which means that the notation rules that apply to the class classifier also apply to the component classifier. If you read and understood my previous article regarding structure diagrams in general, and class diagrams in particular, you are well under way to understanding component diagrams.
In UML 2, a component is drawn as a rectangle with optional compartments stacked vertically. Figure 2 shows three different ways a component can be drawn using the UML 2 specification. The reason? In UML, a rectangle without any stereotype classifier is interpreted as a class element. The Order components drawn in Figure 2 all represent valid notation elements; however, a typical component diagram includes more information.
A component element can have additional compartments stacked below the name compartment. As mentioned earlier, a component is an autonomous unit that provides one or more public interfaces.
Figure 3 shows the Order component having a second compartment that denotes what interfaces the Order component provides and requires. Note: Even though components are autonomous units they still may depend on the services provided by other components.
In the example Order component shown in Figure 3, the component provides the interfaces of OrderEntry and AccountPayable. Additionally, the component also requires another component that provides the Person interface. Note: Figure 3 does not show the Order component in its complete context.
This second approach is illustrated in Figure 4. Interface symbols with only a half circle at their end a. Even though Figure 4 looks much different from Figure 3, both figures provide the same information — i. Figure 5 shows that the Order System component depends both on the Customer Repository and Inventory System components.
In UML 2 the subsystem classifier is a specialized version of a component classifier. Because of this, the subsystem notation element inherits all the same rules as the component notation element. The UML 2 specification is quite vague on how a subsystem is different from a component.
The specification does not treat a component or a subsystem any differently from a modeling perspective. Compared with UML 1.
This change did introduce fuzziness into the picture, but this fuzziness is more of a reflection of reality versus a mistake in the UML 2 specification. So right now you are probably scratching your head wondering when to use a component element versus a subsystem element. Quite frankly, I do not have a direct answer for you. I can tell you that the UML 2 specification says that the decision on when to use a component versus a subsystem is up to the methodology of the modeler.
I personally like this answer because it helps ensure that UML stays methodology independent, which helps keep it universally usable in software development. The component diagram is one of the easier-to-understand diagrams, so there is not much to cover beyond the basics.
However, there is one area you may consider somewhat advanced. Using the example shown in Figure 7, the Store component provides the interface of OrderEntry and requires the interface of Account. The Store component is made up of three components: Order, Customer, and Product components. This square is called a port. Note: In actuality, ports are applicable to any type of classifier i. To keep this article simple, I refer to ports in their use on component classifiers.
By using a port, our diagram is able to de-couple the internals of the Store component from external entities. By connecting to the Account port, the internals of the Store component e.
The required Account interface will be implemented by a component outside of the Store component. Note: Typically, when you draw a dependency relationship between a port and an interface, the dependent requiring interface will handle all the processing logic at execution time.
However, this is not a hard and fast rule — it is completely acceptable for the encompassing component e. You will also notice in Figure 7 that the interconnections between the inner components are different from those shown in Figure 5.
This is because these depictions of internal structures are really collaboration diagrams nested inside the classifier a component, in our case , since collaboration diagrams show instances or roles of classifiers. The relationship modeled between the internal components is drawn with what UML calls an assembly connector. Assembly connectors are drawn as lollipop and socket symbols next to each other. Drawing these assembly connectors in this manner makes the lollipop and socket symbols very easy to read.
The component diagram is a very important diagram that architects will often create early in a project. November 24, June 25, June 18, Web development. Close Close. Article The component diagram UML's method to show the structural relationships between the components of a system.
Deploy with confidence Consistently deliver high-quality software faster using DevOps Continuous Delivery. Software development Web development. Event Meetup Women Born to Code. March 17, January 3, Play outline. Flying a drone with React and Node. May 10, Close Modal.
The component diagram
Component diagram. The Component Diagram helps to model the physical aspect of an Object-Oriented software system. It illustrates the architectures of the software components and the dependencies between them. Those software components including run-time components, executable components also the source code components. Use case diagram Class diagram Sequence diagram Communication diagram State machine diagram Activity diagram Component diagram Deployment diagram Package diagram Object diagram Composite structure diagram Timing diagram Interaction overview diagram. Aggregation Shared association. Association Without aggregation.
Modélisation UML & SysML
Oh no, there's been an error