In this section we consider a case study to examine the feasibility of our proposed QA technique

Analysis of MAPSTEDI System UC Model

The MAPSTEDI system [X] is being developed to allow the University of Colorado Museum (UCM), Denver Museum of Nature and Science (DMNS), and Denver Botanic Gardens (DBG) to merge their separate collections into one distributed biodiversity database. The system will also be used as a research toolkit by geocoders and other users of the system. The use case model of the MAPSTEDI system IS comprised of several use case diagrams, that are used to model different subsystems of the target system. The use case model was accompanied with use case descriptions. The descriptions will play an essential role in examining the validity of the use case diagrams and the model as a whole.

The MAPSTEDI use case model contains five use case diagrams. Each diagram represents a different aspect of the system’s functionality (see Table 5).

Table 5. Description of the use case diagrams of the MAPSTEDI system

Use Case Diagram*	Illustrated Behavior
Administrative Process	Shows the administrative responsibilities
Database Access	Shows who may access the database and how
Database Edits	Outlines the operational mechanisms of editing and updating the database
Database Queries	Provides a hierarchal outlines of the query services offered by the system
Database Integrator	Shows how the separate databases (local and remote) are integrated.

The following are the corresponding use case diagrams:

Fig. 5.1.1. The use case diagram of the “Administrative Process” subsystem

Fig. 5.1.2. The use case diagram of the “Database Access” subsystem

Fig. 5.1.3. The use case diagram of the “Database Edits” subsystem

Fig. 5.1.4. The use case diagram of the “Database Queries” subsystem

Fig. 5.1.5. The use case diagram of the “Database Integrator” subsystem

While performing the matching process, it is important to consider overlapping entities. That is, use cases or actors that exist in more than one diagram. This consideration helps reveal antipatterns that may exist over two or more use case diagrams.

The resulting antipattern matches shown below (see Table 6) require human cognition to verify the correctness of the use case model. As mentioned earlier, the proposed technique must be applied iteratively as corrections and changes upon reviewing an antipattern match might cause new antipatterns to surface. This process is further elaborated as we examine the antipattern matches of the MAPSTEDI system. An analysis of the antipattern matches of the first iteration is shown in Table 7.

Table 6. First Iteration Matches:

Match No.	Use Case Diagram	Antipattern Matched	Elements involved
1.1	Database Access	Multiple actors associated with one use case	Actors: Public User and Research User Use Cases: Download Collections Data, Search Collections Data and Visualize Biodiversity Analysis
2.1	Database Queries	Functional decomposition: Using the extend relationship	Use Cases: All five use cases illustrated in the corresponding use case diagram.
3.1	Database Integrator	Functional decomposition: Using the include relationship	Use Cases: Edit Collections Data and Update Collections Data.
3.2	Database Integrator	Functional decomposition: Using the include relationship	Use Cases: Upload DGB and UCM Data, Run QC Tests and Update Collections Data.
4.1	Database Edits	Functional decomposition: Using the include relationship	Use Cases: Geocode Specimen and Find Locality
4.2	Database Edits	Accessing an extending use case	Actors: Data Editor and Database Integrator. Use Cases: Edit Collections Data and Geocode Specimen.
5.1	Administrative Process	Multiple actors associated with one use case	Actors: Database Administrator and ArcIMS Administrator Use Cases: Backup Process
5.2		Multiple actors associated with one use case	Actors: Database Administrator and ArcIMS Administrator Use Cases: Restore Process
5.3		Multiple actors associated with one use case	Actors: Database Administrator and ArcIMS Administrator Use Cases: Install Software Updates

Table 7. First Iteration Analyses:

Antipattern Match 1.1:

Analysis:

Upon analysis of the three use cases which the Actors Public User and Research User are jointly associated with, the actors were found to have similar roles when executing the use cases

Corrective Actions:

The role that the actors play in correspondence to the three given use cases will be generalized into a separate actor (called User). The generalized actor is then associated with the use cases.

Antipattern Match 2.1:

Analysis:

The extend relationship was used to represent the generalization hierarchy between the query services offered by the system.

Corrective Actions:

The extend relationships should be replaced with generalization relationships.

Antipattern Match 3.1:

Analysis:

The Edit Collections Data use case represents subroutine type behavior that is required by the Update Collections Data use case.

Corrective Actions:

The functionality described in the Edit Collections Data use case should be merged and represented as a “Sublfow” component of the Update Collections Data use case.

Antipattern Match 3.2:

Analysis:

(a)Analysis of the involved use cases show that updating the database requires the DGB and UCM data to be uploaded. Meanwhile, the task of uploading any data requires the execution of Quality Control (QC) tests upon that data.

(b)Furthermore, upon analyzing the Update Collections Data use case, it was discovered that the updating task only occurs if the execution of the use case Query Remote Database returned results.

Corrective Actions:

(a)The Upload DGM and UCM Data and Run QC Tests use cases should be merged into the Update Collections Data use case by modeling each as a separate “Subflow” component. Moreover, the description of the “Subflow” component responsible for uploading the data should indicate a requirement to execute the other “Subflow” that is responsible for running the QC tests.

(b)The Update Collections Data use case contains functionality that is lengthy and optional - with regard to the Query Remote Database use case. Therefore, the include relationship between the use cases should be replaced with an extend relationship.

Antipattern Match 4.1:

Analysis:
The Find Locality use case was supposed to be able to be executed by any user of the system

Corrective Actions:

The Find Locality use case is associated with the generalized User actor from the Database Access use case diagram.

Antipattern Match 4.2:

Analysis:
The Edit Collections Data use case was merged into the Update Collections Data use case as a result of an antipattern match in the Data Integrator use case diagram. Therefore, the actors Data Editor and Database Integrator are now accessing the extending use case Update Collections Data.

(a)Upon analyzing the extended use case Geocode Specimen, it is discovered that updating the database represents part of its required functionality.

(b)The data-editing role played by the Geocoder actor is modeled using the Data Editor actor. However, the Geocoder is the only actor that will be editing the data. Moreover, the model shows that the Geocoder already has indirect access to the Update Collections Data use case, through the Geocode Specimen use case.

Corrective Actions:

(a)The extend relationship between the involved use cases was used to indicate subroutine type behavior. Therefore, this relationship should be replaced with an include relationship. Where the Geocode Specimen use case would be including the Update Collections Data use case. As a result, the Data Integrator actor is no longer directly accessing an extending use case.

(b)Since the Geocoder actor already has indirect access to the Update Collections Data use case, the Data Editor actor is no longer needed and should be removed.

Antipattern Match 5.1, 5.2 and 5.3:

Analysis:
All three antipattern matches suffer from the same issue; the actors involved play the same role when executing any of the three shared use cases

Corrective Actions:

There should be a generalized actor that generalizes the actors present in the use case diagram. The generalized actor maybe called Administrator.

The results of performing the corrective actions from the first iteration are shown in Figures 5.1.5 and 5.1.6. Figure 5.1.7 now shows the latter three use case diagrams merged.

Fig. 5.1.5. The Database Access use case diagram after the first iteration

Fig. 5.1.6. The Administrative Process use case diagram after the first iteration

Fig. 5.1.7. The remaining three use case diagrams (itegrated) the first iteration

The matching process is repeated for the second iteration. Table 8 shows the antipattern matches detected through the second iteration and Table 9 shows the corresponding analyses.

Table 8. Second Iteration Matches:

Match No.

Use Case Diagram

Diagrammatic-Antipattern Matched

Elements involved

1.1

Merged Use Case Diagram

Accessing a generalized concrete use case

Actors: Database Integrator

Use Cases: Query Remote Database and Integrate Query Results.

1.2

Use cases containing common and exceptional functionality

Use Cases: Query Remote Database, Update Collections Data and Geocode Specimen.

Table 9. Second Iteration Analyses:

Antipattern Match 1.1:

Analysis:

This antipattern match resulted from replacing the inappropriately used extend relationships with generalization relationships. The generalized use case Query Remote Database is concrete and is indirectly accessed by the Database Integrator actor through the use case Integrate Query Results.

Corrective Actions:

According to the “Accessing a generalized concrete use case” antipattern, this situation may simply be fixed by setting the generalized Query Remote Database use case to be abstract.

Antipattern Match 2.1:

Analysis:

The shared use case Update Collections Data contains common behavior relative to the Geocode Specimen use case. On the other hand, it contains optional behavior relative to the Query Remote Database use case.

Corrective Actions:

According to the description of the “Use cases containing common and exceptional behavior” antipattern, this technique is appropriate. Therefore, no further corrective actions are required.

After the second iteration was completed, no further antipattern matches were detected. Therefore the final model will be similar to that shown in Figure 5.1.7, with the only exception being that use case Query Remote Database is set to be abstract.

If you have any suggestions or concerns regarding this page, please send an email to the author melattar@ualberta.ca

* The names of the use case diagrams are similar to those used in the use case model document of the MAPSTEDI system