Use cases are useful in capturing the expected and unexpected behavior of the users and the system. However, at some point, the system objects discovered in the process of building the use cases - must begin to take a new form, one that begins to take the activities and behaviors in the direction of software architecture.
What objects are responsible for what activities/behaviors? Have we captured all the use cases and alternate flows that might result from unexpected conditions? Activity Diagrams are useful for discovering behavior not previously thought through by the stake holders who are responsible for providing the requirements of their new system. It allows the business analyst and the systems analyst to put the use cases to the test - and to begin to formalize the architecture, the planned structure of the system.
In this instance, the "View Articles" Use Case is decomposed in terms of its activities.
