A component in an object oriented system is a modular part of the system, where it has required and provided interfaces. On any system design each component should preserve its atomicity, without overloading its functionalities. This means that every component should have a unique set of interfaces to provide and a unique set of interfaces to request from its environment, avoiding duplication and providing the proper reusability. Non atomic components are not so reusable as atomic ones, because they cannot be connected in other tasks. For example if you have an LDAP interface and you want to send SMS notifications to mobile numbers on the directory, you should not plug the SMS notification into the LDAP component, it should be another separate component.
Each component should be analogous to an actor, with its own role, without doubling its functions. This unique role will allow the actor to be meeting its use cases properly. Role duplication can make your architecture and even your code more messy than you think. This also allows decoupling components. Decoupled components will work more cohesively than strongly coupled ones, and role replication will make your components more coupled. Modularity is a key principle while you are designing components. You can start treating your components as actors in your models, this will bring the right use cases and the right architecture for each one of them, mainly using use case diagrams to express their roles.
With each component treated as actor, and even your classes treated as actors, you can clearly visualize the component and class roles. Then you can formalize that set of roles to methods and interfaces to be provided to the environment and requested from the environment. Use cases are not only designed for users, they can be used to represent different nodes in the UML diagrams. So, actors are not only users, they can be components, classes and objects, including applications and systems.
A set of use case diagrams will provide you a clear vision about your component roles. With clear roles you can avoid replication, coupling and overloading. This will also provide you a good design. You can start creating user related use cases, and then your component related use cases, component diagrams, class diagrams, sequence diagrams and then collaboration diagrams, from top to bottom.
Entries 