The\u00a0Unified Modeling Language<\/b>\u00a0(UML<\/b>) is a general-purpose, developmental,\u00a0modeling language<\/a>\u00a0in the field of\u00a0software engineering<\/a>\u00a0that is intended to provide a standard way to visualize the design of a system.<\/sup><\/p>\n The creation of UML was originally motivated by the desire to standardize the disparate notational systems and approaches to software design. It was developed at\u00a0Rational Software<\/a>\u00a0in 1994\u20131995, with further development led by them through 1996.<\/sup><\/p>\n In 1997, UML was adopted as a standard by the\u00a0Object Management Group<\/a>\u00a0(OMG), and has been managed by this organization ever since. In 2005, UML was also published by the\u00a0International Organization for Standardization<\/a> (ISO) as an approved ISO standard.\u00a0<\/sup>Since then the standard has been periodically revised to cover the latest revision of UML. <\/sup>In software engineering, most practitioners do not use UML, but instead produce informal hand drawn diagrams; these diagrams, however, often include elements from UML.<\/p>\n In\u00a0Unified Modeling Language<\/a>\u00a0(UML), a\u00a0component diagram<\/b>\u00a0depicts how\u00a0components<\/a>\u00a0are wired together to form larger components or\u00a0software systems<\/a>. They are used to illustrate the structure of arbitrarily complex systems.<\/p>\n A component diagram allows verification that a system’s required functionality is acceptable. These diagrams are also used as a communication tool between the developer and stakeholders of the system. Programmers and developers use the diagrams to formalize a roadmap for the implementation, allowing for better decision-making about task assignment or needed skill improvements. System administrators can use component diagrams to plan ahead, using the view of the logical software components and their relationships on the system.<\/sup><\/p>\n The component diagram extends the information given in a component notation element. One way of illustrating the provided and required\u00a0interfaces<\/a> by the specified component is in the form of a rectangular compartment attached to the component element.\u00a0<\/sup>Another accepted way of presenting the interfaces is to use the\u00a0ball-and-socket graphic convention<\/a>. A\u00a0provided<\/i>\u00a0dependency from a component to an interface is illustrated with a solid line to the component using the interface from a “lollipop”, or ball, labelled with the name of the interface. A\u00a0required<\/i>\u00a0usage dependency from a component to an interface is illustrated by a half-circle, or socket, labelled with the name of the interface, attached by a solid line to the component that requires this interface. Inherited interfaces may be shown with a lollipop, preceding the name label with a\u00a0caret<\/a>\u00a0symbol. To illustrate dependencies between the two, use a solid line with a plain arrowhead joining the socket to the lollipop.<\/p>\n A\u00a0deployment diagram<\/b>\u00a0in the\u00a0Unified Modeling Language<\/a>\u00a0models the\u00a0physical<\/i>\u00a0deployment of\u00a0artifacts<\/a>\u00a0on\u00a0nodes<\/a>. <\/sup>To describe a\u00a0web site<\/a>, for example, a deployment diagram would show what hardware components (“nodes”) exist (e.g., a\u00a0web server<\/a>, an\u00a0application server<\/a>, and a\u00a0database server<\/a>), what software components (“artifacts”) run on each node (e.g.,\u00a0web application<\/a>,\u00a0database<\/a>), and how the different pieces are connected (e.g.\u00a0JDBC<\/a>,\u00a0REST<\/a>,\u00a0RMI<\/a>).<\/p>\n The nodes appear as boxes, and the artifacts allocated to each node appear as rectangles within the boxes. Nodes may have subnodes, which appear as nested boxes. A single node in a deployment diagram may conceptually represent multiple physical nodes, such as a cluster of database servers.<\/p>\n There are two types of Nodes:<\/p>\n Device nodes are physical computing resources with processing memory and services to execute software, such as typical computers or mobile phones. An execution environment node (EEN) is a software computing resource that runs within an outer node and which itself provides a service to host and execute other executable software elements.<\/p>\n","protected":false},"excerpt":{"rendered":"Component diagram<\/h3>\n
Overview<\/span><\/h4>\n
Diagram elements<\/span><\/h4>\n
Deployment diagram<\/h3>\n
\n