Chapter 9: Components, Deployment, and Higher-Level Modeling


This chapter focuses on the modeling of autonomous units within a system or subsystem that the modeler can use to define software systems of arbitrary size and complexity. The chapter also describes the modeling of the deployment of those units. Finally, the chapter introduces three stereotypes that are useful in labeling packages that contain high-level models.

Components

A component is a named physical and replaceable part of a system that represents the physical packaging and implementation of otherwise logical elements (such as classes). This includes both logical components, such as business components and process components, and physical components, such as Enterprise Java Beans (EJBs), Common Object Request Broker Architecture (CORBA) components, and COM+ and .NET components.

Every component has a contractual obligation to conform to, and provide the realization of, one or more interfaces. As with classes, these are called provided interfaces (see the section "Interfaces, Ports, and Connectors" in Chapter 1). A component can also have required interfaces, as can classes.

Figure 9-1 shows an example of a component along with two each of provided interfaces and required interfaces.


Figure 9-1: Component

Figure 9-2 shows an alternate notation that emphasizes the services that the component needs to call via its required interfaces.


Figure 9-2: Component (alternate notation)

A component may also have ports (see the section "Interfaces, Ports, and Connectors" in Chapter 1).

A component is generally in a realization relationship with one or more classes that implement the interfaces that the component provides. This is the same kind of relationship that a class has with its interfaces; it's just at a lower level of abstraction. (Note that in this context, "implementation" implies a more refined or elaborate form of the client, not necessarily a physical implementation as, say, program code.) Figure 9-3 shows an example of a realization dependency.


Figure 9-3: Realization dependency

Another way that component realization relationships can be depicted involves showing the realizing classes as properties of the component. The notation is comparable to that for the internal structure of classes (see the section "Internal Class Structure" in Chapter 1).

In the context of components, there are two types of connectors, described as follows :

  • A delegation connector links the external contract of a component, as specified by its ports, to the internal realization of that behavior by the component's parts . You use delegation connectors to model the hierarchical decomposition of behavior, where services provided by a component may ultimately be realized by a part nested multiple levels deep.

  • An assembly connector connects a required interface or a port on one component to a provided interface or port on another component. Assembly connectors are the primary mechanism for "wiring" components together on component diagrams (see the next section).




Fast Track Uml 2.0
Fast Track UML 2.0
ISBN: 1590593200
EAN: 2147483647
Year: 2004
Pages: 97

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net