Shadow Use-Cases

Traditionally, use-cases have been viewed from the eyes of the business—that is, the user. In many application domains, however, some use-cases are never properly accounted for. These represent areas of functionality that meet all of the criteria of use-cases but that often have more meaning to the IT staff, which is their “user.” The business sponsor might acknowledge them but often underestimates their impact on the application and the estimated time to completion. These use-cases often end up being budget busters.

I call these shadow use-cases because they are not given their due respect in most applications. Figure 4-4 shows the most common shadow use-cases found across all application domains: Security, Audit, Parameter Maintenance, Archiving, and Architecture Infrastructure.

Often both Security and Audit will show up in “includes” relationships to other use-cases (Process Orders “includes” Security). However, both are usually much more complicated than just logging onto a system (e.g., maintaining users and profiles, application functionality, value-level security, and field-level security). Both should be represented on the business view of the use-case diagram. I worked on one project whose security package alone contained 15 distinct classes and consumed about 500 person-hours to build. All this grew from an innocuous statement found in a use-case pathway: “Clerk is validated by the system.”

Parameter Maintenance is a use-case that tends to consume too many resource cycles in development and also leads to project cost overruns. Items satisfied by this use-case are setting up and maintaining things like code tables and system parameters. These items always end up being hacked together at the last minute. Worse yet, they are maintained by a database administrator through hand-edited SQL statements (nothing against database administrators; I married one so they can't be all that bad!). Tell me that isn't a disaster waiting to happen.

Archiving also belongs on the business view of the use-case diagram, but it typically is given little consideration. Archiving is not as easy as just backing something up and deleting objects. For example, for a project that is complicated by effective dating schemes, what and when to archive something isn't all that straightforward.

Architecture Infrastructure relates to the plumbing that must be in place to allow the layers of the application to communicate—for example, the components that allow a user interface to communicate to the business rules of the application (Remote Method Invocation, RMI; Common Object Request Broker Architecture, CORBA; Component Object Model, COM+). The same applies to communication from the business rules to the data management component (JDBC, Java Database Connectivity). This use-case should not be on the business view of the use-case diagram; rather it should be a use-case specifically for the IT staff.

Although some might argue that these shadow use-cases are simply “nonfunctional requirements” and not use-cases, I contend that they have all the properties of a use-case (i.e., functional entitlement, goal-orientedness, many pathways). Furthermore, if the project doesn't acknowledge them, the estimates for the project will be very skewed. Some of my colleagues come around to my way of thinking after they view the issues from the perspective of the actor, which in many cases is the IT department. In practice, if these items are brought to the surface and treated as first-class use-cases, they will be given the attention they demand and deserve, along with a representative portion of the project budget.