****WORKING DOCUMENT****
2. Important Actors for Public Clouds
Use cases are a well-known tool for expressing requirements at a high level. In this document we briefly and informally describe a set of use cases for cloud systems. We use the following informal definition of a use case.
Use Case: a description of how groups of users and their resources may interact with one or more cloud computing systems to achieve specific goals.
This document adapts the informal use case template from [Cockburn]
The following sections present informal descriptions that focus on: actors and goals, success scenarios, failure conditions, and failure handling (Cockburn's terminology). Table 1 lists the actors that show up in the use cases. Importantly, the actors are disjoint and do not (currently) inherit from one another. We adopt the definition of "actor" given by [Cockburn] to be, essentially, anything with "behavior" such as a person or a program. In our uses cases, we list the actors that participate. In some cases, an "entity" transforms itself from one kind of actor to another by, for example, authenticating itself (becoming an authenticated user). In this situation, the use case lists all the actors that appear at any point in time, and the scenarios of the use case document the points in which actor transitions occur.
Actor Name | Description |
unidentified-user | An entity in the Internet (human or script) that interacts with a cloud over the network and that has not been authenticated. |
cloud-subscriber | A person or organization that has been authenticated to a cloud and maintains a business relationship with a cloud. |
cloud-subscriber-user | A user of a cloud-subscriber organization who will be consuming the cloud service provided by the cloud-provider as an end user. For example, an organization's email user who is using a SaaS email service the organization subscribes to would be a cloud-subscriber's user. |
cloud-subscriber-administrator | An administrator type of user of a cloud-subscriber organization that performs (cloud) system related administration tasks for the cloud-subscriber organization. |
cloud-user | A person who is authenticated to a cloud-provider but does not have a financial relationship with the cloud-provider. |
payment-broker | A financial institution that can charge a cloud-subscriber for cloud services, either by checking or credit card. |
cloud-provider | An organization providing network services and charging cloud-subscribers. A (public) cloud-provider provides services over the Internet. |
transport-agent | A business organization that provides physical transport of storage media such as high-capacity hard drives. |
legal-representative | A court, government investigator, or police. |
identity-provider | An entity that is responsible for establishing and maintaining the digital identity associated with a person, organization, or (in some cases) a software program. [NSTIC] |
attribute-authority | An entity that is responsible for creating and managing attributes (e.g., age, height) about digital identities, and for asserting facts about attribute values regarding an identity in response to requests. [NSTIC] |
cloud-management-broker | A service providing cloud management capabilities over and above those of the cloud-provider and/or across multiple cloud-providers. Service may be implemented as a commercial service apart from any cloud-provider, as cross-provider capabilities supplied by a cloud-provider or as cloud-subscriber-implemented management capabilities or tools |
Table 1 Actors
The following sections organize the use cases by whether they are about the general management, the interoperability between clouds, and by security issues. We believe that the use cases presented in sections 3, 4, and 5 are likely candidates for testing in the SAJACC project. The use cases presented in section 6, "Future Use Case Candidates" will be considered after the earlier use cases have been implemented.