Bug 123276 - multiplicities should be possible for attributes and not just for associations
Summary: multiplicities should be possible for attributes and not just for associations
Status: CONFIRMED
Alias: None
Product: umbrello
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR wishlist
Target Milestone: ---
Assignee: Umbrello Development Group
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-03-08 13:40 UTC by Edward Nash
Modified: 2020-08-13 14:24 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Edward Nash 2006-03-08 13:40:04 UTC
Version:            (using KDE KDE 3.5.1)
Installed from:    Ubuntu Packages
OS:                Linux

The UML spec (and many other UML tools, e.g. argoUML) allow attributes to have a multiplicity (other than 1..1) specified. Although not supported in all targets (e.g. can't be easily implemented in C++), attribute multiplicities are supported in some targets (e.g. XML Schema: element multiplicity) and should be supported in Umbrello.
Comment 1 Edward Nash 2006-03-09 12:20:44 UTC
multiplicities for attributes shown as e.g. + street [0..1] : CharacterString
Comment 2 Josh Hansen 2009-06-26 22:49:09 UTC
This remains an issue over 3 years later, as of version 2.2.90 (from kubuntu's KDE 4.3 beta2 packages).
Comment 3 Robert Hairgrove 2020-08-13 14:10:49 UTC
And, believe it or not, it is still an issue in 2020!

Together with multiplicity and the In/InOut/Out type for parameters, there would be almost no need to define special types for pointers and references (in C++, at least):

For multiplicity of 1:
IN Parameters, if they are datatypes, would be passed by value;
INOUT and OUT parameters by non-const reference;
IN parameters of class type passed by const reference.

For multiplicity of 0..*:
IN parameters should be passed as pointer to const type;
INOUT and OUT parameters as pointer to non-const type.

However, there is quite often the need to model things like char** which would probably need additional constraint extensions if actual pointers as datatypes are added to the existing primitive types.
Comment 4 Ralf Habacker 2020-08-13 14:24:11 UTC
(In reply to Robert Hairgrove from comment #3)
> And, believe it or not, it is still an issue in 2020!
According to https://umbrello.kde.org/openbugs.php there are about 300 bugs open, and it was already hard work to bring the code into the current form; so any help is welcome :-)