Be Advised: Classified, FOUO, and PII Content is Not Permitted
I was trying to find the best model pattern to use in a situation that I think qualifies as "duck typing"...in a class diagram, I needed to define an attribute or argument that is a plain object (sometimes called POJO in Java/Javascript), but the object being referred to is expected to have certain keys defined and must also satisfy a minimum pattern in order to work.
After discussion with Jim Ciarcia, he mentioned that this is one of the inherent limitation of UML...not being able to model something like this exactly. However I still wanted to capture this in the design. We discussed the options of using an interface vs a stereotype, and based on his helpful suggestions here's what I ended up settling upon for how to do this in Cameo:
1) Created a profile element
2) Created a profile diagram
3) Created a stereotype (you cannot set the "Is Abstract" to true or the stereotype won't be available to use in step 7
4) In that stereotype, added the attributes and attribute types I needed
5) In the class diagram, select the class attribute that is the "duck"
6) Define the "Type" as a JavaScript Object (because technically it is a POJO)
7) Set the "Applied Stereotype" to be the one defined in step 3
8) you can do the same thing on an operation's parameter, just open the properties of the paramater and the "type" and "applied stereotype" values can be defined
Additional thoughts I've had are possibly using the stereotype attribute's "default value" and "multiplicity" to indicate which attributes are optional and what default value they will have should it be undefined (i.e. if you give me something that should be a duck it is required to have wings, but you forget to define the color, I'll default to "brown").
The good news is that when you follow this pattern, the default class diagram will show the stereotype for the POJO attribute but I cannot yet figure out how to show it next to the stereotyped argument...not sure I want it there anyway.
If you want to find everywhere in the model that this "duck" is used, there are two easy ways:
Option 1) open the stereotype specification, in the tree select "stereotypes elements" and it'll show a list of all the attributes and arguments where it is applied
OR
Option 2) Right-click the stereotype in the container tree, Related Elements --> Used By, run the search. Then in the results you can filter the "used by" column to see everywhere it is used as a parameter or as a property (attribute).
And of course, just do the reverse when you find the stereotype in a spec of another class...right click the stereotype and click "open specification" or "select in containment tree" and Quack, you'll see your duck specification :)
I think this pattern will be incredibly useful for us because there are a lot of methods & libraries we use that pass arguments using POJOs but it is difficult to trace where those duck-typed POJOs exist in our code. Using this pattern we can now more easily scope a change when the spec for a method or library is modified.
I have no idea if this is the best way to accomplish it, but my goal was to capture where this pattern is used in our design so it can be easily understood and remains traceable. I plan to follow this pattern for similar situations and see how it goes. I welcome other suggestions if there are better ideas out there.
After I shared this with some people via email Jim provided the following additional advice:
"keep the stereotyping simple. Create 2 stereotypes, one for the "duck type" and another of a "duck property". Then apply these to normal UML classes (or SysML blocks) that show what that minimum keys and patterns are. You don't need to put those stereotypes on everything that is duck typed, use the generalization relationship from your normal class/block to the "duck typed" class/block."