Smart use case stereotypes

Front end¶

• Simple Select (1 - Piece of Cake). A use case for selecting a single item from a list of items of a business class.
• Select (2 - Moderate). A use case for selecting a single item from a list of business objects from one class, with some added functionality, such filtering on property values of the business object.
• Multi Select (3 - Average). Use case to select multiple instances from a list, with some added functionality, such filtering on property values of the business object.
• Search (3 - Average). A use case for selecting an single instance of a business object from a list. Search arguments may be use to filter the list.
• Extended Search (4 - Hard). A use case for selecting an single instance of a business class from a list. Search arguments may be use to filter the list. The use case contains additional functionality, such as displaying properties from associated business entities, or filtering items from the list, based on authorisation.
• Manage (3 - Average). A use case that manages maintenance for a single item of a business class. This use case contains additional functionality, such as business rules, comparisons, authorization.
• Define (3 - Average). The same as a Manage use case, but without database access.
• List Detail (4 - Hard). Use case that contains a list of items from a business class and that manages a single instance selected from this list.
• Master detail (4 - Hard). Use case that manages a single item from a business class and a list of items from an associated business class, such as order-orderline.

Reporting¶

• Simple View (2 - Moderate). A use case that shows a single item of a business entity. This use case contains no complex functionality, such a business rules, comparisons, authorisation.
• View (4 - Hard). Use case where an item is viewed, for instance overview of your order, or your new subscription. In most cases, actions can be performed from this use case, such as finalisation of your order, or adding items to a shopping cart. In most use cases several items are displayed.
• Report (4 - Hard). Use case representing a regular report, over one or several business entities.
• Extended Report (5 - Very difficult). Use case representing a complex report, over several business entities, for instance with totals and calculations.
• Graph Report (8 - Extreme, but known). A use case that represents a report over one or more business entities, and containing one or more graphs.

Service orientation¶

• Validate (8 - Extreme, but known). Validation of a (set of) business rule(s). Executing business processes often include specific validation services, for instance to see if an customer is allowed to add a particular product to their subscription. Smart use cases labeled with the validate stereotypes execute the validation (business) rules. In cases of more complex validation, for instance when match-making between different back-end or external systems is required, the validate use case relays fetching the required information to dispatch, read or even aggregate smart use cases.
• Process (5). Use-cases executing a business process. In most cases it delegates the execution of services to other use cases, often of types aggregate and dispatch. The process use case is in the lead, and uses the post-conditions from called use cases to steer the process. This type of smart use cases is generally implemented in the enterprise service bus, such as BizTalk or SAP Xi.
• Aggregate. Use-cases used to create a single response to a request. The stereotype is called aggregate as these use cases trigger other smart use cases, othen of types dispatch and read, and aggregates the results from these use cases into a single response.
• Integrate. Use-cases integrating data which is collected from one source or several sources. These cases can be equipped with additional functionality, such as performing basic checks and preparing or mapping the data for the following step.
• Dispatch. Use-cases which are intended to link the aggregate or process types use cases to services that either require some mapping, or typically run outside the organization. Mapping is often required, as the available services do not always deliver what is required by the calling use cases. The dispatch smart use cases performs the mapping (hence and forth) and relays the work to the actual service, that is often of type read or write.
• Calculate. Use-cases calculating and creating new information based on different business rules. These cases can be equipped with additional functionality such as applying filters and performing basic checks and preparing or mapping the data.
• Read. Use-cases providing basic services. Here one or more domain objects or entities are returned from a back-end system. This often includes compressing a whole hierarchy (such as with many SAP systems), such as a product hierarchy into a single returning message.
• Write. In reverse, write typed smart use cases will pick up such a compressed hierarchy that is input to the use case, distribute the hierarchy into the back-end systems and persist it.
• Inform. During the execution of a business process, the actual user of the whole process (being the actor of the user goal level use case initiating the process) needs to be informed of the status. The actor might get an email, such as in a subscription process to acknowledge successful subscribing, or be sent a letter. Other alternatives are of course also possible. The inform use case is responsible for merging the text of the message being sent with the actual domain objects the use case model evolves around. Often implemented via the so called publish-subscribe mechanism.

• Transfer Object Service (8 - Extreme, but known). Use case implementing interaction with an external service that produces objects, quite often transfer objects. Is rather complex, due to the fact that the objects might be difficult to map to the business entities in your domain.
• XML Service (10 - Extreme and unknown). Use case implementing interaction with an external service that produces XML documents. Is complex, due to the fact that the XML documents in most cases need to be mapped to business entities.
• System Service (10 - Extreme and unknown). Use case implementing interaction with another system, using a complex interface. This type of use case is often split.

File Handling¶

• File Import (8 - Extreme, but known). A use case that implements reading data from (flat) files, such as XML documents or spread sheets. Possibly split. Look for different types of items to read.
• File Export (10 - Extreme and unknown). A use case that writes to a (flat) file, such as XML documents or spread sheets. Possibly split. Look for different types of items to write.

Business inteligence¶

• Collect (5 - Very difficult). Use case that collects data from a source, perform basic checks and prepares the source for staging in.
• Integrate (10 - Extreme and unknown). Use case that integrates data from different sources, perform basic checks and prepares the data for the following layer.
• Aggregate (3 - Average). Use case that aggregates and denormalizes data and performs basic checks to prepare the data for general staging out.
• Calculate (8 - Extreme, but known). Use case that calculates and can create new information based on different rules, applies filters and performs basic checks to prepare the data for the different dependent data marts.
• Present. Use case which complexity is highly dependent on the type of presentation that is required, for instance reporting, graphs, ad-hoc query environment, analysis environment of maybe even the implementation of analytical models.
• Publish (3 - Average). Use case that that is concerned with layout, security and authorization.

Unknown¶

• Unknown (10 - Extreme and unknown). There are times when we just don't know what a specific use case will look like yet. To be able to identify them anyway, we added the stereotype Unknown, which represents a use case with unknown functionality and complexity. Although this sound ackward, use this type to identify still vague use cases for estimation. Split up (and possibly remove) when the use case becomes less vague.