Multiplicity
jonas
The attribute is a 2D array of 4 by 12.
How can I write this attribute down ?
- score : int [12] { Bag }
This is a normal array of 12 elements of the type int. But each
element should be an array of again 4 elements of the type int.
I'm guessing:
- score : int [12][4] { Bag }
RJB
be able handle it.
But, as far as I can tell from the UML standard it is not legal UML --
only a single "Multiplicity Element" is allowed.
On the other hand, people commonly write "void name(int data)" when
the UML is "name(data:int)".
Hope this helps
RBotting
H. S. Lahman
Are you using UML for OOA/D modeling? If not, you can stop reading...
> I'm writting a class diagram that has an attribute of the type int.
> The attribute is a 2D array of 4 by 12.
>
Object attributes are supposed to be scalar values at the level of
abstraction of the containing object. (In relational terms they must be
simple domains.) One can use abstract data types (ADTs) for attributes
to hide more complex data structures. But those data structures most be
manipulated as a whole by any of the object's clients. Thus one can
define an object attribute as a ComplexNumber ADT to hide the real and
imaginary parts, but it will be manipulated as a single value in any
attribute operations. (Supporting this notion is why the OOPLs provide
syntax for operator overloading so that '+' will work correctly in
arithmetic expressions; the OOA/D modeler assumes that sort of support
is available for the ADT.)
So you shouldn't be doing what you are trying to do. Of course there
will be situations where the object's clients will need access to
individual elements of the array. To provide that you have to define a
first class object for the array that has an interface to access the
individual elements (e.g., elementCount, getValue(index), getNext(),
etc.). In fact, the OOPL world is full of such computing space data
holders in class libraries -- String, Array, Stack, etc. -- that one can
model in the OOA/D as ADTs. However, they are treated specially because
it would be awkward to model
<pre>
R1 has 1
[ContainerObject] <*>------------------- [Array]
+ elementCnt
+ getNext()
...
</pre>
every time one wanted a simple array's elements. So we model the OOPL
data holder first class objects as ADTs, like Array. Then we make the
array an attribute with that attribute. When clients obtain the
attribute from the owner, they can access the elements through the ADT
interface. In effect, this is a shorthand the navigates the R1
composition relationship whenever a client accesses the ADT attribute.
> How can I write this attribute down ?
>
> - score : int [12] { Bag }
>
> This is a normal array of 12 elements of the type int. But each
> element should be an array of again 4 elements of the type int.
>
> I'm guessing:
>
> - score : int [12][4] { Bag }
>
This is modeling OOPL syntax. As soon as one mentions something like
'int' one is talking about OOP implementation details that don't belong
in OOA/D models. In effect this syntax is trying to define an ADT
implementation inline.
There are a lot of drawing tools that support this sort of thing as a
convenience to the developer in round-trip development environments. The
ADT needs to be defined some place for the specific computing
implementation environment. In MDA terms such definitions are part of a
Transformation Model that defines how a specific OOA/D maps into a
particular computing environment. Rather that using a separate
Transformation Model, it is convenient to use ADT tags in the UML OOA/D
model to convey this information. But it is important to realize that
those tags are not part of the OOA/D model; they are pass-through
definitions that are only relevant to OOP.
IMO, this is poor practice because it confuses the level of abstraction
of OOA/D vs. OOP when viewing a UML model. It happens to be very
convenient for most round-trip tools because those tools do not use an
abstract action language (AAL) for describing behaviors; they use an
augmented OOPL instead of an AAL, which opens a Pandora's Box of
opportunities for implementation pollution. Such notations allows the
OOPL code direct access of the array's elements very naturally for an OOPL.
None of the true AALs used in translation tools, whose level of
abstraction is at the same level with UML bubbles & arrows, provide any
syntax to access an array this way, so one would not be able to describe
client interactions with the elements from such a tag. Such tools do
separate the ADT definition, but it is still a mouse click away.
--
Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer
H. S. Lahman
H.la...@verizon.net
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html