There are several meta-models and templates for use case textual description. These representations have different goals and viewpoints, thus proposing different concepts, or different relationship between concepts, or even different semantics for a concept.
Because some MDE works need to use a basic use case meta-model as part of the transformation, in this paper in WER 2011; I proposed an essential use case meta-model. This meta-model was based on a survey on existing meta-models and templates (the analysis of these concepts is available in this post).
Due to space limitations, the paper only presents part of the meta-model abstract syntax and semantics (textually). In this post I will make available the full abstract syntax and concrete syntax using XML (for the semantics, please refer to the original paper).
The meta-model’s abstract syntax is presented next, using a MOF class diagram. The Ecore file is available here. The original meta-model was adapted to include three meta-classes: UseCaseModel, Agent and Subject. Agent and Subject were included to represent who executes a Step – if a Subject (the System) or an Actor – an Agent is simply a generalization of Subject and Actor.
On the other hand, UseCaseModel was created to allow several use cases in a model in conformance to this meta-model.
This meta-model have two constraints: (1) a Step has to be on a FlowOfEvents or (exclusively) on a Statement; and (2) that an AlternativeFlow cannot extend one of its Steps. These constraints are represented as annotations in the Ecore meta-model.
context Step inv: self.statement <> null xor self.flowOfEvents <> null context AlternativeFlow inv: self.branchingStep.flowOfEvents <> self
Finally, the meta-model concrete syntax in XML, described using XML Schema, is available here.
If you find any problem or mistake in this meta-model, please let me know. Feel free to extend it, if necessary. And don’t forget to reference the paper, written by me and Paulo Sérgio Muniz Silva.
This meta-model was used in my PhD. thesis, in a transformation from requirements to specifications (using Michael Jackson’s terminology).