Analysis of the CodeCrawler System UC Model

 

The CodeCrawler system is an application designed to view and search through code written in any language. Users of the application can specify parameters for the system to perform the required search tasks. An administrator can change the setting of the application as well as add support for any new language. The following is the original use case diagram for the CodeCrawler system (see Fig. 5.3.1).

 

Fig. 5.3.1. The original CodeCrawler use case diagram.

 

Table 12 shows the antipattern matches detected upon completing the matching process. Table 13 provides analysis of the antipattern matches and a description of any required countermeasures. Many ‘Multiple actors associated with one use case’ antipattern matches no longer exist after corrective actions for previous antipattern matches have been undertaken. Hence, it is recommended that the ‘Multiple actors associated with one use case’ antipattern should not be searched for and addressed in early iterations.

Table 12. First Iteration Matches:

Match No.

Antipattern Matched

Elements involved

1

System depicted as an actor

Actors: CodeCrawler

2

Actor existing within system boundary

Actors: CodeCrawler

3

Incorrect stereotype for relationship

Relationships between use cases:

Search ŕ Perform search

4

Incorrect stereotype for relationship

Relationships between use cases:

Build search index ŕ Swap search index

 

5

Incorrect stereotype for relationship

Relationships between use cases:

Build search index ŕ Abort indexing

6

Incorrect stereotype for relationship

Relationships between use cases:

Add support for new language ŕ Change settings

7

Multiple actors with similar names

Actors: Administrator

 

Table 13. First Iteration Analyses:

Antipattern Match 1:

 

Analysis:

The actor involved in this antipattern is a representation of the CodeCrawler system. Systems should not be depicted as actors as this gives the impression that the system is actually an external entity. As a result of depicting the system as an actor, the actual name of the system is not displayed elsewhere.

 

Corrective Actions:

The actor is removed along with any associated association relationships it has with other use cases. The system name is appropriately depicted near the top part of the system boundary.

 

Antipattern Match 2:

 

Analysis:

This antipattern match no longer exists after the corrective actions for antipattern match no. 1 was undertaken.

Antipattern Match 3:

 

Analysis:

Upon reviewing the descriptions of the Search and Perform search use cases, it is discovered that performing a search (carried out by the Perform search use case) always occurs at the end of configuring the search process (carried out by the Search use case). Hence, the association between the use cases is that of an include relationship rather than a generalization relationship.

 

Corrective Actions:

The generalization relationship between the use cases is removed and replaced by the more appropriate include relationship.

 

Antipattern Match 4:

 

Analysis:

Similar to antipattern match no. 3, the swapping activity of the search index (carried out by the Swap search index use case) always occurs upon completion of building the search index (carried out by the Build search index use case). Hence, the association between the use cases is that of an include relationship rather than a generalization relationship.

 

Corrective Actions:

The generalization relationship between the use cases is removed and replaced by the more appropriate include relationship.

 

Antipattern Match 5:

 

Analysis:

Upon reviewing the descriptions of the Build search index and Abort indexing use cases, it is discovered that abortion of the indexing process is an exceptional situation that is not in aid of the nominal success scenario. Hence, the association between the use cases is that of an extend relationship rather than a generalization relationship.

 

Corrective Actions:

The generalization relationship between the use cases is removed and replaced by the more appropriate extend relationship.

 

Antipattern Match 6:

 

Analysis:

Upon reviewing the descriptions of the Add support for new language and Change settings use cases, it is discovered that the system’s settings can be changed in several ways. Adding support for a new language is a special type of change to apply to the system. Hence, the generalization relationship between the use cases is appropriate and should remain. However, the <<uses>> stereotype is misleading since it is usually used to stereotype an include relationship.

 

Corrective Actions:

The <<uses>> stereotype should be removed.

 

Antipattern Match 7:

 

Analysis:

The actor Administrator is depicted twice in the diagram. This raises the question of whether there are two types of administrators with different job duties. If such is the case, then the actors should be assigned names that are more descriptive and specific to their duties. However, the use case descriptions do not indicate that there are two types of administrators.

 

Corrective Actions:

The Administrator actor is depicted only once with all association relationships being assigned to it.

 

Fig 5.3.2. shows the use case diagram upon completing the required corrective actions. A second iteration yielded further antipattern matches. Table 14 outlines the antipattern matches detected in the second iteration while Table 15 shows the corresponding analyses.

 

Fig. 5.3.2. The Code Crawler System use case diagram after the first iteration

Table 14. Second Iteration Matches:

Match No.

Antipattern Matched

Elements involved

1

Functional decomposition: Using the include relationship

Use Cases: Search ŕ Perform search

2

Functional decomposition: Using the include relationship

Use Cases: Build search index ŕ Swap search index

 

Table 15. Second Iteration Analyses:

Antipattern Match 1:

 

Analysis:

 

Use case Search is responsible for allowing the primary actor Developer to specify a certain setting whereby the search will be conducted by the system. Use case Perform search is only a task that is required to complete this goal. The secondary actors Store and Codebank do not benefit from the use case Perform search. Instead, use case Perform search utilizes these actors to provide the required service for the Developer.

 

Corrective Actions:

 

The behavior described by the Perform search use case should be merged into the Search use case, since the actual service offered to the Developer is the ability to search for code using a setting specified by the Developer. The Perform search use case can then be removed from the diagram along with the associated include relationship.

 

Antipattern Match 2:

 

Analysis:

 

Upon reviewing the descriptions for the Build search index and Swap search index use cases, the actual service provided is to both build and swap the search index. Hence, both functionalities provided by the use cases are sequenced using the include relationship.

 

Corrective Actions:

 

The behavior described by both use cases should be merged into one new use case called Build and Swap search index.

 

 

Fig. 5.3.3 shows the use case diagram upon performing the corrective actions indicated in the second iteration. A third iteration revealed two ‘Multiple actors associated with one use case’ antipattern matches. Both matches proved to be false positives since the actors involved with the given use cases perform different roles when interacting with the use cases. Hence, no further actions were required.

 

Fig. 5.3.3. The Code Crawler System use case diagram after the second iteration