Use cases from the perspective of software objects.

Use cases from the perspective of software objects? What does that mean exactly. Well, it is misleading in the context of contemporary use case modeling. When I first encountered use cases, I have to say I was less than impressed. There are actors and uses cases. Big deal. Why can't we just hear what needs to be built, go out and build it, and iteratively evolve the software accordingly. Boy was I wrong.

The importance of understanding what is being built is so important that it cannot be underestimated. Especially as software grows ever more complex.

Typically, actors are the users of the system being modeled. For example, you may have a user actor that represents a generic user of the system. You may also have an administrator actor that inherits from user. This works well for modeling the actions the users of the system can perform as well as actions only administrators can perform. Actors also represent external systems in use case diagrams. This provides a new perspective of how your system uses external systems or how your system is used by external systems.

But what about modeling software objects as actors? This is completely valid and a very powerful abstraction tool. Modeling what your system will do in a standard use case diagram is a challenging task on its own. The next step is to realize this functionality. Once some software objects have been conceived, we can then conceptualize how these objects will behave by modeling them as actors in a use case diagrams.

Alternatively, software objects can be modeled in use case diagrams as the system boundary, or system context. Your software object essentially becomes the system you are modeling.

Modeling software objects as in uses cases can help discover interfaces that your various objects will both require and provide.