Modeling your design
If your team works with other teams on a large project, problems that occur when the teams integrate code can be costly to fix. Your team can help prevent these problems by using models to understand the interfaces of each component and how they fit together before your team starts coding.
The Components of Your Application
Component diagrams show how an application or component is made up of parts wired together. Each part's type is a smaller component. A component can be anything from an individual object to a substantial system, and the connectors between them can represent method calls, event signals, web service calls, and so on.
At the surface of a component are its provided and required interfaces. Provided interfaces are those that other components can use. Required interfaces are those for which the component depends on other components.
.png "UML component diagram showing parts")
Required interfaces allow you to represent a component that is separable from both the components that use it and the components that it uses. A clear understanding of this separation is important for the team to be able to test the component in isolation, using mock objects to plug into the required interfaces.
The explicit depiction of required interfaces often leads to more cleanly separated and more flexible designs. The components, when implemented, can readily be recombined with other components to make a variant of the system, leading to greater agility in response to requirements changes.
Models of the components should be no more detailed than is useful at each iteration. For more information, see UML Component Diagrams: Guidelines.
Interactions between the Parts
Use sequence diagrams to help discuss or explain how a component will work. Represent each port or part of the component by a lifeline. A diagram can show how, when a message is received at one of the parent component's ports, the internal parts interact along the paths of the connectors.
For more information, see UML Sequence Diagrams: Guidelines.
The Interfaces of the Components
Draw class diagrams to show the types available at the interfaces to the components.
Start with each interface and show its methods.
Then show the types of the parameters and return values of the interfaces. Draw properties as associations.
Where an interface sends XML or other data structures, you might find it useful to draw the structure using a UML class diagram.
These diagrams can be useful in discussions of the component behavior. They also help to separate discussions of the externally visible behavior from the internal implementation.
Design Patterns
Models are also useful to help describe recurrent patterns. Just as the Observer pattern (for example) is applicable to a wide variety of applications, many projects find configurations of objects that are useful for their particular purposes. You can use class and sequence diagrams to describe the interacting classes.