| Summary: | support for utility classes | ||
|---|---|---|---|
| Product: | [Applications] umbrello | Reporter: | Oliver Kellogg <okellogg> |
| Component: | general | Assignee: | Umbrello Development Group <umbrello-devel> |
| Status: | CONFIRMED --- | ||
| Severity: | wishlist | ||
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
|
Description
Oliver Kellogg
2004-09-09 15:03:29 UTC
> A class with the stereotype <<utility>> might be generated as a package
> without a tagged type in Ada.
Or as a namespace with plain (non class-member) operations, for that matter.
I'm not sure though whether the UML standard blesses such a mapping.
Import could be done using the following rules:
Ada package without any subprograms
=> UML package
Ada package with subprograms which are all primitive operations of tagged types
=> UML package
Ada package with subprogram(s) which are non primitive on a tagged type
=> UML class with stereotype <<utility>>
Using a fixed set of rules implies that code may be generated different from its imported form.
For example, according to the above rules, an Ada package containing several tagged types would be imported as a UML package with nested classes. However, on generating Ada code from the UML, the nested classes would be generated as child packages.
The best solution would certainly be to allow the user to specify the mapping per Ada package (choose between UML package and utility class on import) but that is difficult to implement.
|