GreaterCause Use Case Summary
This section documents each use case package independently. The packages are explained using use case diagrams and, where appropriate, activity diagrams are shown as well. The documentation also consists of a high-level summary of main and alternate flows of events for each use case.
Manage Donor and Donations
This package pertains to donor-related services. These services primarily include donor registration, making donations, managing the shopping cart, and providing donors with the ability to view their donation history (a.k.a. tax record) for the current and previous year.
| Tip | The activity diagram of Figure 1-6 is focused on communicating a single aspect of the system, and that is "Making a Donation." Use more activity diagrams to show other aspects of the system. Activity diagrams can be used to explain systems, subsystems, class, operations, and use cases. You want to create activity diagrams mostly for explaining complex processes. |
| Note | The activity diagram of Figure 1-6 depicts the flow of events when a donor selects an NPO to donate to. The diagram clearly articulates the various processes involved in completing a donation process. The readers of the documentation will find it helpful to have a high-level view of certain complex sequences of events, especially the ones that illustrate a process flow. |
Manage Donation Cart Use Case
This use case handles the process of displaying, adding, removing, and modifying donations in the donation cart.
Main Flow of Events The use case is instantiated when a donor selects an NPO on the search results page, or selects the donate function for a featured-NPO in a portal-page. The donor is presented the donation cart with the selected NPO added to the cart. The donor enters the donation amount for the new donation. At this time, the donor can also modify donation amounts for existing donations and maybe decide to remove existing donations from the cart. The donor confirms the changes by selecting the checkout or update function, thus ending the use case.
| Note | In the preceding use case, notice that the emphasis is on behavior rather than the user interface. Wire frames depicting user interactions are developed as part of information architecture in Chapter 2. Wire frames, coupled with navigation semantics, will further augment the use cases. |
Alternate Flow of Events If the donor is making a donation for the first time, the donor is presented with a registration form. The donor verifies the registration information, some of which could have been provided by the affiliated portal-domain, and submits the information to the system. The system validates this information and presents the new donor with a form that enables a donor to provide a set of preferences that personalizes a donor's donation experience. The donor provides this information to the system, which validates and stores the information in the database for future use. The donor is then presented with the donation cart.
Checkout Use Case
This use case interfaces with the credit card processor and creates transaction history. At the donor's discretion, this use case can also update credit card information.
Main Flow of Events The use case is instantiated when the donor selects the checkout function. The donor is presented with a checkout page. The donor has the option of changing the credit card information on this page and saving the new credit card information as part of the checkout process. When the donor confirms, the information is validated. If the validation is successful, the credit card processor is contacted. If the credit card transaction is successful, include (Update Donation History) for creating transaction history of all donations in the donation cart and include (Manage Donation Cart) for clearing the cart. A thank you page is presented to the donor, thus ending the use case.
Update Donation History Use Case
This use case records all transaction history.
Update History Main Flow of Events The use case is instantiated by the checkout function. Completed donations from the checkout function are added to the data store, and the use case ends.
Display Donation History Use Case
This use case also displays a cumulative history of a donor's donations for the current year and, optionally, the previous year. The current year's history is shown by default; the previous year's history is displayed only when selected.
Display History Main Flow of Events The use case is instantiated when a donor selects the reporting function. The system displays the transaction history for the current year, and the use case ends.
Display History Alternate Flow of Events The donor can select to display the previous year's history.
Register Donor Use Case
This use case creates a new donor in the GreaterCause data store.
Main Flow of Events The use case is instantiated for an unregistered donor. The donor is provided with a registration page. The registration page is initialized with a registration ID, and donor-related information provided by the portal-domain. The donor verifies or modifies the information. If the information entered by the donor is validated successfully, then use include (Manage Donor Preferences) and the use case ends.
Manage Donor Preferences Use Case
This use case enables a donor to input personal preferences for customizing his or her donation process.
Main Flow of Events The use case is instantiated either by the donor registration process or when the donor selects to modify his or her personal preferences. The donor makes the required changes and confirms. If the information entered by the donor is validated successfully by the system, the donor preferences are updated in the data store. The system acknowledges the changes and the use case ends.
Search NPO
This package provides the search functionality to donors, the site administrator, and portal-alliance administrators. NPO entries are analogous to items in a catalog. Searching a non-profit organization is analogous to searching an item from the catalog; in this context, the non-profit organization is itself an item in the supply-chain sense.
Search NPO Use Case
This use case provides search algorithms for searching the NPOs. A generic keyword-based search is available along with an advanced search capability for location-based searches.
Keyword Search Main Flow of Events This use case is instantiated when the donor uses the generic keyword search function. The system searches the database for matching NPOs and displays a results page to the user, and the use case ends.
Advanced Search Main Flow of Events This use case begins when the donor, the site administrator, or the portal-alliance administrator selects the advanced search function. The user is presented with a query page. The user enters the search criteria. The system searches the database for matching NPOs and displays a results page to the user, thus ending the use case.
Figure 1-7: Use case diagram—Search NPO
Perform GreaterCause.com Site Administration
This package enables the maintenance of the configuration information for proper operation of the site. Key facilities provided by this package are NPO registration, portal alliance registration, profile maintenance, and portal-specific UI customizations.
| Tip | Actors can be organized using the generalization relationship. The inheritance semantics are the same as that in classes; the child inherits the behavior of the parent and can add to or override this behavior. For example, in Figure 1-8 the site administrator inherits from the NPO and portal-alliance administrators. Because Java does not support multiple inheritance, it is likely that during implementation the site administrator will extend a base class that has implemented the interfaces for NPO and portal-alliance administrators; this will allow the site administrator to be substituted wherever NPO and portal administrators can appear. |
Register NPO Use Case
This use case is responsible for registering new NPOs for the site. Every NPO, prior to registration, is verified for validity. The NPO verification is an offline process.
Main Flow of Events The use case begins when the site administrator selects the NPO registration function. The site administrator enters all the necessary information pertaining to a non-profit organization. The system validates the information. If the validation process is successful, the system stores the registration information in the data store. The system initializes an NPO profile record, acknowledges the actions, and the use case ends.
Manage NPO Profile Use Case
This use case enables the site administrator and NPO administrator to change the profile information associated with an NPO.
Main Flow of Events The use case starts when an NPO or site administrator selects the update profile function. The administrator is presented with a page with relevant profile information. The administrator updates the information and confirms changes. If the validation process is successful, the system commits those changes in the data store. The system acknowledges the changes, and the use case ends.
Register Portal-Alliance Use Case
This use case is responsible for registering new portal-alliances for the site. Only registered portal alliances can redirect their users to the GreaterCause.com site for making donations.
Main Flow of Events The use case begins when the site administrator selects the portal-alliance registration function. The site administrator enters the necessary information associated with the portal-domain. The system validates the information. If the validation process is successful, the system stores the registration information in the data store. The system acknowledges the actions, and the use case ends.
Manage Portal-Alliance Profile Use Case
This use case enables the site administrator and portal-alliance administrator to change the profile information associated with a portal-domain.
Main Flow of Events The use case starts when a portal-alliance administrator or site administrator selects the update profile function. The administrator is presented with a page with relevant profile information. The administrator updates the information and confirms changes. If the validation process is successful, the system commits those changes in the data store. The system acknowledges the changes, and the use case ends.
Perform UI Customization Use Case
This use case empowers the portal administrator and GreaterCause.com site administrator to provide portal-specific UI customizations. These customizations preserve the look and feel of the portal-domain when the users affiliated with a portal-domain are accessing the GreaterCause services.
Main Flow of Events The use case begins when the site administrator or portal administrator selects the UI customization feature. The administrator provides the location of a portal-specific custom navigation bar's HTML for portal branding. The system acknowledges the changes, and the use case ends.
Manage Campaigns
This package enables the portal administrators and site administrators to create portal-specific campaigns for featuring selected NPOs at both the global and regional levels. The campaign creation service is available only at the GreaterCause.com site. A list of featured-NPOs associated with active campaigns is made available as a Web service by GreaterCause for consumption by portal-domains. The portal-domains extract this information via the Web service and cache it locally. Subsequently, the portal-domains can exhibit the featured-NPOs in their portlets from a local cache rather than fetching that information from the GreaterCause.com site for every user signing on to the portal.
Create Campaign Use Case
This use case provides site and portal administrators with the ability to create campaigns for selected NPOs. NPOs could be promoted at the global or regional level, but no more than five NPOs can be displayed in the portlet (pass-through UI component) at any given time.
| Caution | Be careful when using extend relationships. It is possible to end up with an extend relationship for simple logic. For example, in Figure 1-9, for use case Manage Campaigns we could have factored two variants, Manage National Campaigns and Manage Regional Campaigns, as two new use cases that extend the behavior of Manage Campaigns. For now, it is best not to express these variants as separate use cases because their behavior is only marginally different from each other. |
Create Campaign Main Flow of Events The use case starts when the portal administrator or the site administrator selects the new campaign function. The search facility is invoked for finding the desired non-profit. The administrator selects a non-profit from the search result page. The system displays a campaign detail page with the selected NPO. The administrator enters the campaign dates and optionally a region code. The administrator then submits the information. The system validates the information and, on successful validation, saves the campaign in the data store. The system acknowledges the changes, and the use case ends. Figure 1-10 illustrates the Create Campaign main flow events.
Figure 1-10: Activity diagram for Create Campaign
Update Campaigns Use Case
This use case provides site and portal-alliance administrators the ability to modify existing campaigns.
Update Campaigns Main Flow of Events The use case starts when a portal or site administrator selects the function for modifying existing campaigns. The administrator either selects the global campaigns or supplies a region code for selecting regional campaigns for a specific region. The system displays the available active campaigns. The administrator modifies and submits the campaign information. The system updates the data store, thus ending the use case.
Provide Featured-NPO List Use Case
This use case enables the extraction of featured-NPOs for a given portal-domain. The featured-NPOs are made available to the portal-domain via a Web service.
Main Flow of Events This use case is instantiated as a result of Web service invocation. The GreaterCause.com domain provides the featured-NPO list to the portal-domain via the Web service, and the use case ends.
NPO Caching
This package enables the retrieval of a list of featured-NPOs from the GreaterCause.com domain; after the NPOs are retrieved, they are stored in a local cache.
Figure 1-11: Activity diagram for Update Campaigns
Cache Featured-NPOs Use Case
This use case enables the caching of featured-NPOs. The portlet that represents a pass-through to the GreaterCause.com site uses this cache to display featured-NPOs, associated with active campaigns, to portal users.
Figure 1-12: Use case diagram—NPO Caching
Main Flow of Events This use case is instantiated when the portal-domain invokes a Web service. The Web service provides a list of featured-NPOs that are retrieved and cached within the portal domain, thus ending the use case.
Portal Pass-through
This package enables the fetching and display of the cached featured-NPOs associated with active campaigns. The featured-NPOs are displayed in the GreaterCause-specific portlet provided within the portal page. The donor can choose to donate to one of the featured-NPOs. A donate action will signal the system to redirect the user to the GreaterCause.com site.
| Tip | An ambiguity in the activity diagram is caused when two outbound transitions are specified for an activity or action state. For example, in Figure 1-13, we could put a self-recursion on Display National Campaign and Display Regional Campaign to display a maximum of five featured-NPOs, and then an outbound transition from these activity states to the next activity states; this will make the transitions ambiguous. Instead, you should implement an iteration logic with action states to set and increment the value of an iterator, and implement a decision node (branch node) to evaluate the completion of all iterations; only after the iterations are completed will you transition to another activity or action state. |
Figure 1-13: Use case diagram—Portal Pass-through
| Note | The activity diagram of Figure 1-14 uses swimlanes to depict the activities across both the portal-domain and GreaterCause domain. The purpose of this diagram is to clearly show the activities and transitions within and across each domain. Swimlanes can be also be used for showing interactions between different subsystems and business objects. |
Figure 1-14: Workflow for making a donation to a featured-NPO
Display Featured-NPOs Use Case
This use case displays global and regional featured-NPOs in the GreaterCause portlet within the portal.
Main Flow of Events The use case begins when the portal-page is displayed to the portal user. The portlet's logic will display the featured-NPOs available in the local cache. A maximum of five NPOs are displayed, starting with NPOs associated with national campaigns. The successful rendering of the portlet within the portal's page terminates the use case.
Redirect to the GreaterCause.com Site Use Case
This use case is responsible for routing a portal user to the GreaterCause.com site.
Main Flow of Events The use case begins when the portal user selects the donate function for a featured-NPO. The portal-domain mutually authenticates with the GreaterCause.com domain. GreaterCause.com then generates an authentication token that will identify a valid redirection. The portal-domain assembles donor-specific information required for registration, and packages the token supplied by the GreaterCause.com domain. The system then redirects the donation request to the GreaterCause.com site with donor-specific information, along with the choice of NPO, thus ending the use case.
Alternate Flow of Events The portal user can select to pass-through to the GreaterCause.com site without selecting the donate function for a featured-NPO. In this case, the portal user is taken to the advanced search function of the GreaterCause application.
EAN: 2147483647
Pages: 111