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>\u00a0(ISO) as an approved ISO standard.\u00a0<\/sup>Since then the standard has been periodically revised to cover the latest revision of UML.<\/sup>\u00a0In 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 A\u00a0component<\/b>\u00a0in the\u00a0Unified Modeling Language<\/a>\u00a0represents a\u00a0modular<\/a>\u00a0part of a\u00a0system<\/a>\u00a0that\u00a0encapsulates<\/a>\u00a0the\u00a0state<\/a>\u00a0and\u00a0behavior<\/a>\u00a0of a number of\u00a0classifiers<\/a>. Its behavior is defined in terms of\u00a0provided<\/i>\u00a0and\u00a0required<\/i>\u00a0interfaces<\/a>, is\u00a0self-contained<\/a>, and\u00a0substitutable<\/a>. A number of UML standard\u00a0stereotypes<\/a> exist that apply to components.<\/p>\n A component has an external and internal view, also known as “black-box<\/a>” and\u00a0“white-box”<\/a>, respectively. In its external view, there are public properties and operations. For its internal view, there are private properties and realizing classifiers and shows how external behavior is realized internally.<\/sup><\/p>\n A component may be replaced at\u00a0design time or run-time<\/a>\u00a0by another if and only if their provided and required interfaces are identical. This idea is the underpinning for the\u00a0plug-and-play<\/a>\u00a0capability of\u00a0component-based<\/a>\u00a0systems and promotes\u00a0software reuse<\/a>.<\/sup>\u00a0Larger pieces of a\u00a0system<\/a>‘s functionality may be assembled by reusing components as parts in an encompassing component or assembly of components, and wiring together their required and provided interfaces.<\/sup><\/p>\n A component acts like a\u00a0package<\/a>\u00a0for all model elements that are involved in or related to its definition, which should be either owned or imported explicitly. Typically the classifiers related to a component are owned by it.<\/sup><\/p>\n Components of a system are modeled by means of\u00a0component diagrams<\/a>\u00a0throughout the\u00a0development life cycle<\/a>\u00a0and successively refined into deployment and run-time.<\/sup><\/p>\n In diagrams, components are shown as a\u00a0rectangle<\/a>\u00a0with the keyword \u00abcomponent\u00bb. Optionally, in the right hand corner a component icon can be displayed. This is a rectangle with two smaller rectangles protruding from its left hand side. If the icon symbol is shown, the keyword \u00abcomponent\u00bb may be hidden as seen to the side.<\/p>\n","protected":false},"excerpt":{"rendered":"Component (UML)<\/h3>\n