I basically have a class like the following:
class Stack {
...
push()
pop()
isEmpty()
...
class StackIterator extends Iterator {
...
hasNext()
next()
...
}
}
and I want to create a UML state diagram for the iterator. My idea was to use a dependency arrow and Stack calls to model the Iterator states as follows:
Would this be a valid, industrial proof and fully understandable UML state diagram for situations like this?
A state machine can be the behavior of an operation, but to associate a state machine to a class is very strange and out of UML because a class does not have a behavior.
A dependency between state machine has no predefined meaning in UML. You want to indicate the inheritance between your classes but while a state machine does not have to be associated to a class that dependency is not relevant
[edit]
For people having a doubt about the fact a state machine can be the behavior of an operation, I encourage you to look at the norm :
StateMachine inherits Behavior (§14.2.2 of formal 2017-12-5)
Operation inherits BehavioralFeature (§ 9.6.2)
a BehavioralFeature is implemented (realized) by a Behavior (§ 9.9.2))
Note the behavior of an operation can also be supported my an Activity being also a Behavior
In order to show the behavior of the stack you should simply use an activity diagram. The filled/empty states are superfluous and you get the guard for the pop with the [size >=1 ] condition easily.
Btw. nothing is endless. The push should have a [size < max] or the like.
Related
class Foo{};
class Demo
{
public:
std::unique_ptr<Foo> foo_ptr{new Foo()};;
};
What's the relationship between Foo and Demo? I think it is composition. Am I right? How to draw such the relationship between them?
For the occasion that the variable member is not the type of std::unique and alike, at the association's end which tell that the class at the opposite has an attribute named after the role，e.g:
.
Then for the type of std::unique<T>, how to add the attribute?
Indeed, the relation between Demo and Foo that is implemented using std::unique_ptr is a kind of composition:
The unique_ptr ensures exclusive ownership of a Foo object
The unique_ptr ensures control of Foo‘s lifecycle, i.e. as you pointed out destruction of Demo implies destruction of owned Foo.
The fact that a unique_ptr can be moved is not an obstacle to the composition. On contrary, such transfers are explicitly allowed in UML.
It seems preferable to state a 0..1 multiplicity on the side of Demo, since your code does not require that all Foo instances necessarily belong to Demo:
I would not use the dot notation here, as I think it could mislead to think that Demo has a Foo member whereas Demo has only a unique_ptr that implements the composition of Foo. You could however use an open arrow on Foo side to document that the association is navigable in that diraction (via the pointer). Although there is no other semantic in UML behind this arrow, it could elegantly and informally suggest a pointer pointing to a target.
I can (right now) not give an answer to the notion of generics, but I can try to clarify a few things.
Your class code shows a public attribute foo_ptr which is initalized with an instance of a generic class being Foo. This is a simple attribute and you could denote that like
(generics aside!)
There is no need to make that foo_ptr a composite aggregation. The latter is about object lifetime. And that should be derived from business requirements rather than from some implementation.
Composite aggregation means that the class instance is obliged to destroy the composite whenever it is terminated. So clearly some runtime implementation detail. If, and only if, that is the case then you add a filled diamond next to Demo. Else you go with a simple association.
As I learned the chosen language construct ensures that explicitely. However, if you go back to abstraction you need to document the cause for composite aggregation (which can not be found in the presented code). Just adding the diamond is only half of the truth. There must be some requirement/constraint that led to this construct.
I have this attribute in Java:
private final Object MUTEX = new Object();
How can I show the init of a new Object in the UML Class Diagram?
EDIT:
The attribute MUTEX is used only for synchronized (MUTEX) operation.
So I was wondering if the initialization of this variables is needed to be specified in a UML class diagram, but i'm not sure if this initialization is behavior like or structural specific.
A class diagram is meant to show structure. As a part of structure you can show initial values of properties as answered in this question.
To show the operation "in progress" you need to create a Sequence Diagram where you can show behavior. The question would be: why? A simple initialization is usually not worth it. And from the skinny context of your question it does not appear to be the case. So the best is to go with above answer.
Edit (past your question edit) This is just structure and you will show it like this:
I have class Controller in my java project, which has method like this:
As you can see, in the first line I am getting Singleton instance of ActualModes class and call method getActualModes().
So the first question is, which relatinship I should use in class diagram.
After that I am creating new instane of ModeContext class and then call method executeStrategy. In this case, which relatiship is better ?
It should be like this:
Access to the singleton (note the stereotype which is just convenient and no obligation or general standard) is anonymous and so you just have a dependency. The ModeContext in contrast uses a private (I don't know the scoping rules of the language you used, so I made it pivate) property called context. Note the dot which is saying exactly that.
Disclaimer: UML does not specify a mapping between Java and UML, so every answer to your question is open for debate.
I think both relationships are dependencies, drawn as dashed arrows from Controller to ActualModes and from Controller to ModeContext. The definition of 'dependency' according to the UML 2.5 specification (§7.8.4.1) is:
A Dependency is a Relationship that signifies that a single model Element or a set of model Elements requires other
model Elements for their specification or implementation.
An example of a type of relationship which is in my opinion less suited, is the association, although its definition (§11.5) is quite broad:
An Association classifies a set of tuples representing links between typed instances. (...) An Association specifies a semantic relationship that can occur between typed instances.
One could argue that there are links between Controller and the other two classes, in the form of variables, but these variables are local method variables, which exist only temporarily during the execution of the method. Associations represent more durable links, e.g. class members - as far as I understand UML and as far as I have seen associations used in practice.
I'm taking a Data Analysis course, we're covering UML class diagrams. I keep getting confused by the terminology of methods (operations) and constructors. What is the difference between a method and a constructor? Any explanation would be greatly appreciated, the light bulb for this just hasn't lit yet and hope some outside perspectives will help. Thank you in advance!
Some of the confusion has historical reasons where terms were defined only partially (or not at all). The current UML spec 2.5 defines on p. 114
9.6.3.1 Operations
An Operation is a BehaviorialFeature of an Interface, DataType, or Class. An Operation may be directly invoked on instances of its featuringClassifiers. The Operation specifies the name, type, Parameters, and Constraints for such invocations.
Sounds a bit like blurb, but basically this is what a programmer would call a function.
Method in contrast (which formerly has been used alternatively to Operation) is defined on p. 13
For example, an operation owned by a class may have a related method that defines its detailed behavior.
So the method is the "how to" of an operation and can be described by various means like e.g. a StateMachine and more.
Finally a Constructor is a certain operation which by is executed during initialization of an object. On p. 15:
Therefore, when modeling the detailed behavior of the instantiation of a classifier, it is a modeler responsibility to ensure that the modeled behavior carries out the proper initialization of any attributes with default values once the object is created. (This is often done by encapsulating the instantiation behavior for a class in a constructor operation – see sub clause 11.4 – in which case the initialization of the attributes becomes an implicit postcondition for the constructor.)
The hierarchical representation of finite state machines in UML 2.0 gives great information compression so you don't have to describe all possible state combinations. UML also provides so called orthogonal states that is they aren't mutually exclusive.
And as far as I undertand this idea, if an object produces some activity in these states in response to the same event, activities corresponding to each state should simply be combined. The question arose while working on reverse engineering UML State Machine Diagrams from legacy C++ code. The refined C++ code and UML diagram are given:
void CSomeClass::somePublicMethod()
{
if (false == m_A)
{
return;
}
if (true == m_B)
{
m_C = otherMethodWithSideEffects();
}
if (false == m_C)
{
// some logic with side effects and state transitions
return;
}
// other complex logic with side effects and state transitions
}
UML state machine diagram:
On the one hand states B and C aren't completely independent, on the other hand the notion of concurrent states makes diagram much simpler. Can you suggest a better solution or
tell me where I'm wrong?
Do you have a real problem where a "parallel" or "non exclusive" state machine applies ?
Seems you are looking for a very theorical concept. You diagram example, doesn't show any "transitions values", looks more like standard flowchart. ( Yes, I know, state machines are specialized flowcharts )
A hierarchical state machine should have "encapsulated" or "hidden" transition values as well.
U.M.L. flowcharts also have support to represent "parallel" or "non exclusive" paths, so if you have to model that kind of case you may want to start with them, instead of state machines.
The only hierarchical state machines I have work are related to parsers, altought, I know they are also used in electrical circuits.
Good Luck.