Smart use cases are a great technique for specifying standardized requirements in many types of projects. Over the past few years we have smart use cases being modeled and written in projects using Java and .NET, as you might expect, but also in Sharepoint projects, business intelligence, service oriented projects and even SAP implementations.
Stereotypes drive standardization
Standardization of your requirements can be an important driver to simplify software development and software rejuvination projects. An important addition to the smart use case modeling technique is the use of smart use case stereotypes.
These stereotypes represent often occurring patterns of requirements. Well known our the stereotypes manage, that represents a maintenance use case on some domain object, or search, which helps users to find a particular domain object, guided by search criteria. Other known stereotypes include select, master-detail, view, and report. As you might expect, these stereotypes all deal with user interaction.
Over the years however, we have gathered quite a few stereotypes, also in other fields. We have described for instance stereotypes that deal with Extraction Transformation Load (ETL) processes in data warehousing projects, such as aggregate, calculate and load.
Stereotypes not only help to put focus in modeling workshops, they also facilitate more easy project estimates, and even allow for straightforward code generation and isolated testing. Even better, once you marked the stereotypes (and put them into a UML profile), it will allow you to create much richer use case diagrams, modeling in colour.
Modeling in colour using (profiled) smart use case stereotypes
Slicing service oriented projects
More recently we have applied smart use cases to service oriented projects. These projects tend to be more complex than regular software development projects, and focus around more elaborate architectures Service oriented projects mostly include:
- Flexible front-end features. These can be either web pages, mobile phone front ends, Windows native applications or even Flash or Silverlight applications.
- Process-oriented middleware. Service oriented processes always implement business processes. These business processes or workflows are run in middleware, more specifically in an enterprise service bus (ESB), although having such a bus is not mandatory. There are many vendors supplying busses, such as IBM, SAP, Oracle and Microsoft.
- Stable services. A very important part of service oriented projects consists of the discovery and realization of services. Most often these services are implemented on top of existing legacy or packaged systems.
These slices in service oriented project all serve particular means and responsibilities. The approach to modeling smart use cases in such projects offers quite a few benefits. Next to modeling the front-end use cases, smart use cases help to model the business processes, and discover the required services.
Stereotypes for service oriented projects
In recent projects, that involved such complex service oriented architectures, we have gained a lot of experience in identifying and modeling smart use cases. This week we have analized a number of such models from different projects. This results in a set of new smart use case stereotypes, specifically targeted at the processes that run in middleware, and the encapsulation and execution of services.
One of the smart use case diagrams we’ve investigated
Next to our well-known front end smart use case stereotypes, the new service oriented stereotypes include the following: process, aggregate, dispatch, validate, read, write and inform. I will elaborate on these stereotypes in the next sections.
A use case of stereotype process executes 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.
An aggregate typed smart use cases generally is 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 singel response.
Smart use cases of type dispatch 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 dipatch 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.
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 (as in one of the projects we investigated). Smart use cases labeled with the validate stereotypes return a single answer, that can be either a yes or no response, or a single value from a limited list of possible codes.
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.
Smart use cases with the read stereotype are the most 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.
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.
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.