Come as you are, feeling happy!: Deal with Component Diagram

Component diagram
Component diagrams is considered as an architecture-level artifact, either to model the business software architecture, the technical software architecture, or more often than not both of these architectural aspects.

Components in UML could represent:

UML 2.0: logical components (e.g., business components, process components)
UML 1.0 physical components (e.g., CORBA components, EJB components, COM+ and .NET components, WSDL components, etc.),

Physical architecture issues or particular hardware issues, are better addressed via UML 2.0 deployment diagrams or network diagrams.Those diagram uses artifact as a source of a deployment to a node.

Artifact: An artifact is a physical unit, such as a file, executable, script, database, library, source, documetn etc.

Component diagrams are particularly useful with larger teams. Your initial architectural modeling efforts during first cycle should focus on identifying the initial architectural landscape for your system. Component diagrams are great for doing this as they enable you to model the high-level software components, and more importantly the interfaces to those components. Once the interfaces are defined, and agreed to by your team, it makes it much easier to organize the development effort between subteams.

Interfaces
Represents a group messages or calls or an object information that a component implements and that other components or external systems can use.

Sample diagram

Stereotype
Stereotype is abstract metadata or category or template or kind of a component (noted by myself).
The names of these stereotypes are listed below, together with a brief description of their meaning.

«component» - generic type
«subsystem» - generic type
«infrastructure» - the component represents database or service or network, etc.
«entity» - the component represents some collection of persistent data that represents a business concept
«implement» - the component has no formal definition itself, but implements a component stereotyped as a «specification» (to which it is related via a dependency)
«process» - a component that executes a transaction of some kind
«realization» - a component that has classifiers implementing behavior specified elsewhere
«service» - a stateless, functional component that computes a value
«specification» - specifies a component without defining how it will be implemented (i.e. it has provided and required interfaces but no classifiers)

And there is no restriction, you could apply your own stereotype as long as your team understand what it means.

Delegate connector vs Assembly connector

Dependency between components exist on the definition level (top part of the diagram). They can be drawn between the required and provided interface, between a component and interface or even between two components (no interfaces), depending on what we want to show.

Assembly is completelly different relationship and it does not make sense on the definition level (between components). It's because it is a special kind of link - a relationship established in run-time between two instances of a classifier (here - component, the lower diagram).

Creating component diagram strategy
1. Keep components cohesive.
A component should implement a single, related set of functionality. This may be the user interface logic for a single user application, business classes comprising a large-scale domain concept, or technical classes representing a common infrastructure concept.

2. Assign user interface classes to application components.
User interface classes, those that implement screens, pages, or reports, as well as those that implement “glue logic” such as identifying which screen/page/… to display should be placed in components with the application stereotype.

3. Assign technical classes to infrastructure components.
Technical classes, such as those that implement system-level services such as security, persistence, or middleware should be assigned to components which have the infrastructure stereotype.

4. Identify domain components.
A domain component is a set of classes that collaborate among themselves to support a cohesive set of contracts. The basic idea is that classes, and even other domain components, are able to send messages to domain components either to request information or to request an action be performed. On the outside, domain components appear simple, actually they appear like any other type of object but, on the inside, they are often quite complex because they encapsulate the behavior of several classes.

5. Merge a component into its only client.
If you have a domain component that is a server to only one other domain component, you may decide to combine the two components.

6. Pure client classes don’t belong in domain components.
Client classes don’t belong in a domain component because they only generate messages, they don’t receive them, whereas the purpose of a domain component is to respond to messages. Therefore, client classes have nothing to add to the functionality offered by a domain component and very likely belong in an application component instead.

7. Highly coupled classes belong in the same component.
When two classes collaborate frequently, this is an indication they should be in the same domain component to reduce the network traffic between the two classes. This is especially true when that interaction involves large objects, either passed as parameters or received as return values. By including them in the same domain component you reduce the potential network traffic between them. The basic idea is that highly coupled classes belong together.

8. Define component contracts.
Each component will offer services to its clients, each such service is a component contract.

Graphic notation

The major elements of UML component diagram - component, provided interface, required interface, port, connectors.

Notation	Description
Component
WeatherService Component	Component is notated by a classifier symbol with «component» keyword. This notation was introduced inUML 2.0.
UserService Component	Optionally, a component icon that is similar to the UML 1.4 icon can be used in the upper right-hand corner of the component symbol.
External view of User Services component - it provides IUserServices interface and requires IOrderServices interface.	External view or black box component notation - showing a listing of the properties of a component - the interfaces and/or individual operations and attributes listed in the compartments of a component box.
CustomerEJB Component in UML 1.x notation	For backward compatibility reasons, the UML 1.4 notation with protruding rectangles can still be used.
Provided Interface
Weather Services component provides (implements) Weather Forecast interface.	A provided interface is the one that is either realized directly by the component itself, or realized by one of the classifiers realizing component, or is provided by a public port of the component.
Required Interface
User Services component requires IOrderServices interface.	A required interface is either designated by usage dependency from the component itself, or designated by usage dependency from one of the classifiers realizing component, or is required by a public port of the component.
Component Realization
Component UserService realized by UserServlet and UserDAO.	A component realization is notated in the same way as the realization dependency i.e., as a general dashed line from implementing classifiers to realized component having hollow triangle as an arrowhead.
White box view of User Services component - it is realized by UserServlet and UserDAO and manifested by UserService.jar artifact.	Internal classifiers that realize the behavior of a component may be listed in the additional «realizations» compartment - internal, or white box view of a Component. Compartments may also be used to display a listing of any parts and connectors, or any implementing artifacts.
Component UserService realized by UserServlet and UserDAO.	Internal classifiers that realize the behavior of a component may be displayed nested within the component shape.
Delegation Connector
Delegation connector from the delegating port to the UserServlet part.	A delegation connector is a connector that links the external contract of a component (as specified by its ports) to the realization of that behavior. It represents the forwarding of events (operation requests and events): a signal that arrives at a port that has a delegation connector to one or more parts or ports on parts will be passed on to those targets for handling. A delegation connector is notated as a connector from the delegating port to the handling port or part.
Delegation connector from the delegating port to the simple port of SearchEngine.	If the delegation is handled by a simple port, then the delegation connector may optionally be shown connected to the single lollipop of the realizing component.
Delegation connector from the simple port of Authentication component to the delegating port.	If the delegation is handled by a simple port, then the delegation connector may optionally be shown connected to the single socket of the component that requires the interface.
Assembly Connector
Assembly connector between ports of Authentication and Customers components.	An assembly connector is a connector between two or more parts or ports on parts that defines that one or more parts provide the services that other parts use. Assembly connector is notated as a connector between two or more parts or ports on parts.
Assembly connector between simple ports of Authentication and Customers components.	When an assembly connector connects simple ports (ports that provide or require a single interface), it may be notated by a "ball-and-socket" connection between a provided interface and a required interface.
Assembly connector that assembles three parts.	Where multiple components have simple ports that provide or require the same interface, a single symbol representing the interface can be shown, and lines from the components can be drawn to that symbol. This presentation option is applicable whether the interface is shown using "ball-and-socket" notation, or just using a required or provided interface symbol.