Chapter 6 Building Implementation Diagrams


Components

A component is a physical, replaceable part of a system that packages implementation, conforms to and provides the realization of a set of interfaces. It can represent a physical piece of implementation of a system, like software code (source, binary or executable), scripts, or command files. It is an independent piece of software developed for a specific purpose but not a specific application. It may be built up from the class diagram and written from scratch for the new system, or it may be imported from other projects and third party vendors.

A component can be created in the following diagrams:

The symbol of the component is as follows:


A component provides a 'black box' building block approach to software construction. For example, from the outside, a component may show two interfaces that describe it, whereas from the inside, it would reflect both interfaces realized by a class, both operations of the interfaces being the operations of the class.

A component developer has an internal view of the component: its interfaces and implementation classes, whereas one who assembles components to build another component or an application only has the external view (the interfaces) of these components.

A component can be implemented in any language. In Java, you can implement EJB, servlets, and JSP components, for example.

For more information on other types of components: EJB, servlets, JSP and ASP.NET, see chapter Working with Java and Working with VB .NET.

If you start developing a component with classes and interfaces in an OOM and you later want to store them in a database, it is possible to create a manual mapping of objects so that OOM objects correspond to PDM objects. Similarly, if you have an existing OOM and an existing PDM and both models must be preserved; you can handle the link between the object-oriented environment and the physical database through the object to relational mapping. Using this mapping, you can make your components communicate to each other and evolve in an object environment, as well as retrieve data stored in a database.

For more information on O/R Mapping, see the "Understanding O/R mapping" section, in the "Working with Object-Oriented Models" chapter.

 


Copyright (C) 2006. Sybase Inc. All rights reserved.