Is it possible to define the use cases outside of the groups?
I'd like to be able to do something like:
actor Guest as g
usecase "Eat Food" as UC1
usecase "Pay for Food" as UC2
usecase "Drink" as UC3
usecase "Review" as UC4
package Restaurant {
UC1
UC2
UC3
UC4
}
g --> UC1
UC1 --> UC2
etc..
But I'm getting an error, using the package and the alias. Is there another way to structure this to get it to work?
Or do I need to nest the use cases within the group's {}? E.g:
actor Guest as g
package Restaurant {
usecase "Eat Food" as UC1
usecase "Pay for Food" as UC2
usecase "Drink" as UC3
usecase "Review" as UC4
}
g --> UC1
UC1 --> UC2
What you want to do is not feasible in plantuml. The first reason is that plantuml uses the first graphical scope (top level, package, rectangle) where a use-case appears. For example:
This rule can be observed if nesting this snippet in a rectangle or package: XYZ would then be enclosed in this nesting graphical scope.
According to this principle, if your snippet wouldn't be blocked by a syntax error, all your use-cases would be shown at top-level and the package would remain empty.
The syntax error from which you suffer seems to be related to a parsing bug. Indeed, aliases are well recognized in associations. New aliases introduced in associations by default are actors, but an alias alone on a line, be it new or already defined, be it in a package or at top level, is considered as a syntax error. Here are some example of valid use of aliases:
As said, if this error would be resolved, it would still not solve your problem, as this workaround using the syntax without alias, shows (and completely useless in view of what you want to achieve):
Note however that plantuml's approach are more in line with UML packages. In UML the package is not a graphical element in which you position elements, but a a namespace, meaning that two packages could use the same use case name for two different use cases, e.g.
Restaurant.UC1andCantine.UC1, using the package name as prefix to disambiguate . Plantuml does not support this yet. But if it will, the current syntax would make it backwards compatible.