Are there any tools out there that let you model how a class (or a class hierarchy) can change at runtime? For example, if I have a given number of mixin classes that will be combined at runtime and I don't know which ones will be combined until the program runs, how do you go about diagramming that type of runtime behavior?
Here's a better example. Let's say that I have a base class called IceCream, and I have over 100 possible flavors that all derive from that one IceCream class. Let's also suppose that any instance of the IceCream class can be combined with another instance of the IceCream class to create a completely unique IceCream type altogether. Given this domain, how do you use a graphical model to actually say that any one of these types can be combined at runtime?
It would be inefficient to model all the possible combinations of IceCream types, given that there can be a virtually infinite number of permuations for these 100 IceCream types. So again, here's the question: Are there any graphical modeling languages that let you specify this sort of behavior?
Your design sounds a little disturbing. If two different ice creams have different behavior, then why is it wrong to model all the possibilities? Where are you loading the behaviors from? It very well could be the case, but if so I'd guess that you want to contain the behavior instead...
If they don't have different behaviors, then all you are talking is a class "IceCream" with a "Flavor" member. Never create a second class when the only difference is data--the code must actually differ in the two cases to warrant different classes.
If I totally missed something I apologize.
Edit: Let me be more specific about "Containing behavior". If each of your ice-cream flavors had a "Taste" (which is code) and the taste is different between Vanilla, Strawberry and Chocolate--then you have 3 "Taste" ice-cream classes that are contained in one "Cone" class.
The Cone class would be what I think you are trying to model as "IceCream". Since the cone contains all three, a "Lick" method can combine those three in any way possible. Either you can lick(bottom), lick(middle) or lick(top), or you can just lick() and allow the lick method to combine all three into a single call (to be more real-code, you might pass a single variable to lick() that would be forwarded to all contained flavors).
I wonder if the personal db approach of Bento or DabbleDB could be relevant for the actual modelling part. Then maybe the Django admin's model introspection for the logic part. Sounds like you want to create an interface to a scripting language. A kind of vpl library. So, a beefed up and more reflective Django admin might be a starting point.
In general, if you want to create UML class diagrams you can exploit Generic Types in UML. Also, there is the concept of Template Parameters in UML.
Have a look at this site: Defining Generics with UML Templates
They use the Eclipse Modeling Framework as a tool.
Related
I have to model a situation where I would like to use specializations to ensure classes are somewhat normalized, but:
Risk multiple inheritance problems, especially in the long run
Will need to derive an XML-compliant UML model from it (a.o., only one superclass allowed)
The simplified situation is as follows (see also diagram below): we have Parts, like doors, bolts, wheels, etc., and Tools, like drills, ladders, and bigger machinery. All of these may be used in generic processes, like Orders, Shipments, etc. As such, I would like to have one superclass (Powertype, maybe?) that represents them, say Item.
Both Tools and Parts have specialized classes that carry a serial number. As such, I figured that a SerializedItem class with a SerialNumber, which both SerializedPart and SerializedTool inherit, would ensure that all serialized 'things' we have carry at least the same information. However, I also need these Serialized items to carry at least the same information as their more generic parts, and hence I would introduce multiple inheritance.
I have considered making the Item classes interfaces. This would at least mitigate some (many, all?) multiple inheritance problems. This is where another however comes in: aside from an attribute SerialNumber, I would also like to enforce that all Serialized specializations have an aggregation relation with a Manufacturer. Aggregation to an interface is not allowed, so I feel like I cannot with one relation to the superclass enforce this relation.
As such, I have the following considerations/problems:
Have two disjoint 'branches' of Item, with little to no technical governance on content of Serialized specializations
Item classes as Interfaces, but then little governance w.r.t. use of Manufacturer by Serialized specializations
All concrete classes, but then there exist multiple inheritance issues which must be solved when trying to derive XML classes from the model
Which option would you prefer, and why? Did I miss any considerations?
If you want to have a (platform-independent) information design model (similar in spirit to a conceptual model), then you should use multiple-inheritance if this reflects the concepts of your problem domain.
According to such a model-based engineering approach, your model is a pretty good design model that can be used as a basis for making (platform-specific) implementation models such as, e.g., a Java class model or an XML Schema model.
For making an XML Schema model, you would have to choose a certain mapping. In particular, you need to choose a mapping for resolving the multiple inheritance pattern, see also https://stackoverflow.com/a/27102169/2795909.
I just would not make SerializedItem a superclass. Nothing is a serialized thing which generalization would mean. Things can conform to a serialization protocol which is the same as implementing an interface (maybe called Serializable). If you happen to deal with serializable things without bothering about their content you would just deal with Serializable and only know the number.
Basically you should make your SerializedItem an interface (eventually renaming it to Serializable), remove the generalization upwards and make the two horizontal ones realizations.
This is probably not an ultima ratio. But to me this approach sounds more reasonable.
I would like to to create a sequence diagram to show some interaction, and then use that sequence diagram as an interaction occurrence (sub-sequence) on other sequence diagrams. The point is I would like to apply the sub-sequence each time to a different object instance that is involved in the interaction in the sub-sequence. In my case the instances are simply various file artifacts. Is there any legitimate way of doing this prescribed by UML?
EDIT: some more clarification of my context:
I have 2 main sequence diagrams where I want to reuse the sub-sequence as an interaction occurrence
on the 1st main sequence there is one file for which the sub-sequence has to be applied 3 times
on the 2nd main sequence there are 3 different files for which the sub-sequence has to be applied 3 times
the files are read by the same object instance
I model reading from a file by a call arrow stereotyped as <<read>> to a on object instance which represents the file.
I need to reference the file somehow in the sub-sequence, but I haven't found a good and simple way of doing this.
Complicated, but formally (almost) correct solution with Collaborations
Just using InteractionUses is not enough, because this doesn't allow you to assign the actual roles in the main interaction to the generic roles of your used interaction.
Collaborations, CollaborationUses and Role Bindings can be used for this.
See my example here:
This defines a Collaboration with generic roles sender, relay and receiver and shows the interaction between them.
You can now use this collaboration in a concrete situation:
Class S uses the Collaboration two times with different role bindings to its parts (A, B and C are assumed to be able to send and receive Sig1).
With these definitions you can now create your main sequence diagram:
Unfortunately, this is not correct UML, even though there is an example in the specification (I filed an Issue https://issues.omg.org/browse/UMLR-768). You will have to fake this notation until the taskforce comes up with a fix. How to fake it, depends on how strict your tool implements the specification.
Advantage: formally correct and versatile solution, backed by an example in the specification
Disadvantage: complicated and difficult to explain, not completely usable, because of a bug in the specification
Basically there are three different ways to specify such situations.
Using a gate. Whith gates you specify the sequence with messages that start or end at a gate that is defined and in most tools (if usable at all) not shown explicitly. Instead it is modelled with messages starting or ending at the interaction border.
Similar as gates are lost and found messages. These are special messages that pass out the control to another sequence or returns from one. Such as in the case before you can define a set of further diagrams specifying the interaction in more details.
Using abstraction, which is my favorit for most of the cases. This means you extract the common interface from the classes and specify the interaction against the interface instead of the concrete classes.
Use an Interaction with Parameters:
Now we would like to reference the Lifelines of the main Interaction in the arguments of the InteractionUse. Unfortunately, in UML this is not possible, since arguments are ValueSpecifications and they cannot reference another modelelement.
However, NoMagic suggested and implemented an additional ValueSpecification, called ElementValue, that does exactly this. I think this would be a valuable addition to UML and hopefully it will be added some day. Up to then, only MagicDraw users can use this solution (as far as I know).
With this non standard element, we can model this:
The connection between the lifelines is now via the arguments for the parameters of the generic interaction. Technically the lifelines would not need to be explicitely covered by the Interaction Use, but I think that it makes sense to do it (shown in my tool with a non standard circle on the border of the Interaction Use).
Advantage:
compact and versatile solution, almost conformant to the standard
Disadvantage:
uses a non standard model element, currently only available to MagicDraw users.
pragmatic non conformant solution with covered lifelines:
The collaboration and parameter solutions allow to specify it (almost) formally correct. However, in many cases, a simplified model would be sufficient. In your case, for example, you only have two participants and they have different types. So, even though there is no formal connection between the lifelines of the used interaction, and those of the main interaction, there would be no ambiguity. You could use the covered attribute of the InteractionUse to specify, which of the lifelines (files) you are targeting at a specific InteractionUse. Could that be the pragmatic solution, you are looking for?
Advantage:
compact solution
Disadvantage:
not conformant to UML, ambiguous in more complicated situations
I am currently making a domain model of a combat game, and I have difficulties determining whether certain elements should be a class of their own or attributes of some class. For example, I have used a category list to determine the following ideas/objects: Fighter, Level, Weapon, Armor, Attributes, Skills, Arena, Game Mode, Game Log, Opponent.
For example, I can't tell whether Level, Weapon, Armor, Attributes, Skills should be simply stated as attributes of a fighter or should they be delimited as their own object. I can't tell either if an opponent should be a distinct class since it is ultimately a fighter object with an 'attack/defend' association to another fighter.
How does one determine what would be the correct choice for each element in a category list? Can these be subjective?
FYI, I am using Craig Larman's "Applying UML and Patterns" 3rd Edition as an information source.
To clarify your question for a moment -- each Class in your domain model will have a set of Attributes. The question I think you are asking is whether the Type of each of these Attributes should be a Class themselves, or some other data structure (e.g. a struct, enum, primitive etc.)
If this is correct, then the answer comes down to design choices that stem from your analysis; there is no one 'correct way' -- this is the art of software design. There are however a few key things you might want to look for in making your decision:
Evidence of behavioural requirements. Does the object that an Attribute refers to need to encapsulate behaviour itself? Clearly it's impossible for certain data structures to encapsulate behaviour, which may lead you to make choices towards those that can (e.g. a class vs a struct).
Complexity of data structure. Does the object that the Attribute refers to need to encapsulate complex data structures? (e.g. multiple, possibly hierarchical, data of various primitives and/or complex types) Or is it simple? (e.g. a single integer value). Again, complexity in structure will limit how you can represent it.
What are the non-functional requirements of your system? (e.g. performance requirements?) NFRs like performance, scalability and security may constrain your design choices, so that you might choose to represent complex types in simple ways or eliminate behavioural needs etc..
Does the design choice help you or hinder you? There's no point in representing something in an overly complex way that hinders your work or the system.
Audience. This is possibly the most important point -- who are you putting the domain model together for, and what are you trying to communicate to them?
So, for example, you could represent "Weapon" as an attribute typed as a class or using a simple type. Does "Weapon" have behaviour of its own? Does it contain multiple complex data? Is there a NFR that means it can only really be treated as an enum? And so on.
What is the best way to represent a "mixin" using UML?
As documented in this article:
In object-oriented programming languages, a mixin refers to a defined
amount of functionality which can be added to a class. An important
aspect of this is that it makes it possible to concentrate more on the
properties of a particular behaviour than on the inheritance
structures during development.
I will give more details about my particular use case.
I have a collection of classes that model different types of objects. Because all of them can be stored on a storage, I want to use a mixin to implement all the functionality related to "being stored".
Of course, I can use abstract classes but I do not like it because these classes should be part of a different hierarchy of classes and the fact that they can be stored is only a secondary property.
Another option can be to use composition and add the "storage node" as a field of this classes. I do not like this option either for the same reason: I do not want to create any dependency between the classes and the storage.
I have already implemented the solution in Java using a mixin based on dynamic proxies and I would like to document the solution with a clear UML class diagram. Is there a standard way to represent this mixin?
I am also wondering whether it is a good idea to model also how the mixin has been implemented (using proxies) or it is better to use a more abstract representation.
Thanks
Actually there are many ways to model this in UML:
One approach could be to stereotype the operations and properties with <<mixin>> or the like and then use tagged values to describe where you got them from.
Another (I'd prefer) is to actually use a <<mixin>> stereotyped Generalization and attach a note to that telling which operations/properties should be mixed. That would give the implementer a guide to just "lean implementation of the general class".
Eventually you could create <<mixin>> sub-classes with subsets of the ops/props you want to mix in the final class and then Generalize from those.
Probably one could come up with more solutions. Use an approach which suits you best. There is not generic mixin pattern in UML (to my knowledge).
For example let's say we have a class called "Secretary" and another class called "Utils"
Utils has some functions that do general stuff, for example finding the maximum of 3 integers.
"Secretary" needs to call some of these functions and in this class these functions are called using the following notation:
Utils.function()
now my question is, what kind of association, if there is any, exists between these two classes?
Most likely Dependency. Associations are normally used to capture some relationship that has meaningful semantics in a domain. So, for example, Secretary 'works for' Manager. Your example is different: you're not capturing meaningful relationships among instances. Therefore Dependency is probably most appropriate.
More importantly though: what are you trying to illustrate? Remember to use UML like any other tool - make it work for you. So, for example, it's fine to show a binary association if (a) it helps you and/or (b) it helps you communicate with other team members. The fact that it doesn't comply with the intended UML usage doesn't matter - as long as you find it useful.
hth.