The following example walks through an illustration on how to break down an application into components. The first step is to identify all of the logic in the application by employing use cases. Figure 2 displays all of the user cases for a user of the system.

We will focus on one specific example, the registration use case. After identifying the use case, an activity diagram is used to model the detailed business logic for the use case. You can view the activity diagram in the following graphic.

See Figure 3

The last step is to use sequence diagrams to display the logical flow data for the activity diagram. These diagrams are used for validating and documenting analysis and design. The sequence diagram depicts the behavior of messages in chronological order by fine-grained functional area. In this sequence diagram we can see the functional responsibility layout.

As we saw in the previous example, the Registration data validation and e-mail confirmation logic can be further broken out into individual components since they may be used in several applications.

It is now the architect's responsibility to check to see if the component exists. If it does not, the architect must design the reusable component. Taking the case of the e-mail confirmation component, the architect will again lay out use cases and sequence diagrams. Dissecting an application should be no different than designing a small component. In this case, designing the e-mail confirmation component requires numerous sequence diagrams and it also contains several other components. Even in the sequence diagram for this smaller component, two other components immediately jump out - a generic data access component and the e-mail address validation logic. Each of these functional areas would be built as components as well. For more documentation and other information please view the component here (http://software.topcoder.com/catalog/ c_component.jsp?comp=10616127).

See Figure 4

In conclusion, building components and properly architecting component-based solutions is not an easy task. Properly engineering a system for component reuse takes a significant amount of work in addition to building the components themselves. The best approach is to look to a third-party vendor for generic reusable components and internal developers to create the proprietary mission-critical services. This approach takes advantage of reduced component construction cost while at the same time allowing a company to benefit from the economy of scale that components provide.

• Figure 5