I want to model a method which occurs when a specified time has elapsed and an attribute which disappear with class and sequence diagram.
Here is the situation: Workers are working in a factory where they use machines. Each machine can be used by 0-10 workers. Every machine has a repair time limit whereupon the workers have to repair it. It also has a time limit whereupon if the workers miss the repair, the machine explode and the worker or workers dies (bigger then the first one). There are different machines. Some of them have longer time limit, some of them have shorter. All machines are machine oiled which lasts for a while and it gradually loses its strength until it disappears. This value the same for all machines.
My class-diagram:
I saw this solution for the repaireTime and explodeTime can handle with qualifires counting the elapsed time, but I do not see how does a tick increase the qualifiers value. Is it behave like an attribute like this?
At last, how does the machine oil disappear works? It is just an attribute what must be deleted but I do not understand where to count the elapsed time for this and then delete it.
EDIT:
Your sequence diagram appears to be fine.
Your class diagram is however misleading:
The class diagram is a structural diagram, and not a behavioral diagram. SO you don't really care for elapsed time unless it appears in a property or an operation.
The navigation arrow between Machine and Timer does not facilitate the proposed sequence diagram, which assumes that the Timer knows to find the Machine.
Isn't the association with worker end and with works end not the same associations in the end, if considered at the general level?
The qualifier for the elapsed time is not correct.
For the time based association between Machine and Worker, you could consider making this a many to many association, with an association class defining the time-slot (start and end time, from which you can calculate the duration). You may find here some information about how to work with timeslods (although you do not need the additional constraints mentioned in that other question).
Edit: review of your updated diagrams
The class diagram looks better. Some advices:
Class and Subclass1 are probably Machine and E1 ?
Is the duration association class specific to Subclass or is it general for any Class? In the latter case, you should draw it between Worker and Class. It is not necessary to repeat it for Subclass, since the specialisation automatically inherits the associations, properties and operations of its generalisation.
If the Timer has to send messages to objects? The dependency relation therefore seems misplaced. Shouldn't it then have an association with the classes to the instances of which it shall send messages?
How does the Timer know about new Duration objects ? Does it need to know Duration objects or couldn't it send ticks to the machines, which would forward the ticks to the durations?
On the sequence diagrams, and independently of the impact of the above-mentioned advices, it is important to realize that lifelines do not represent classes, but objects that belong to the classes. The class-names should therefore be preceded by a : or an object name and a :.
The second diagram would be integrated in the first diagram if you'd go for the tick forwarding. Nevertheless, if you'd keep it, you should ask yourself how a Duration could check if elapsed_time==timeExplode since timeExplode is a property of the machine and not of the duration.
Related
In my domain model diagram, I have a class Area that is defined by multiple sensors (eg:temperature sensors), but each sensor can be on one area at a time. As I can move the sensors, I can change the sensors to another area, and in the ultimate case delete the area (because an area needs sensors to exist).
Knowing, Area has already and attribute data:Data.
How can i keep track of previous Areas?
eg:
time=0 - Area A has sensors 1,2,3
time = 10- Area A has sensors 2,3
time =20- Area A has sensors 3
I want to be able to go to previous states of the instance, and check which sensors belonged to the area at a certain time t.
Current diagram:
You can use a qualified association with the timestamp as qualifier. This is shown with a small rectangle at the Area end of the association with the text t:Timestamp in it.
PS: In your diagram an Area can exist without Sensors, since the multiplicity is 0..*. You should change it to 1..* if you want this semantics.
The qualifier is an interesting approach. However, it requires to know the precise timestamp of the start of an Area assignment to access the current or an historically associated area. Moreover the history goes in both direction, unlike the qualifier which is inly at one end.
For these reasons the association class would be more suitable:
the association class keeps track of the history, with a begin and end date.
the association with the current period could simply have no end date. Since an association class has reference
semantic (and identity), you could change the end date of the current association, once it’s no longer the current one.
navigation in both direction can take into account the chronology.
The only challenge is to express
the multiplicity constraint at any given time, as the association would become many to many: it’ll be more difficult to tell that there is only one area for a sensor at any given time. Programmatically (for the implementation), it’ll not be a big deal to implement this. But expressing this in OCL, taking into account possibly overlapping intervals it’s more difficult. Fortunately, as qwerty_so indicates in the comments, it’s perfectly valid to express the constraint in plain english.
N.B. additional comparison of an association class and a qualified association for similar problems, here on SE.
A common multi-threaded implementation is to have some class where Method_A() is running in a thread and sits blocked waiting for some signal/event member variable (e.g. WaitForSingleObject).
Interacting classes running in different thread will then call Method_B() which does some work, sets the signal/event variable, perhaps does some more work, then returns.
How do I represent this interaction on a Sequence Diagram?
Should I have two lifelines, one for each thread, even though they are operating on the same instance of the class? My modelling tool (Enterprise Architect 12) doesn't allow the same class to appear twice on a Sequence Diagram, so seems to discourage this.
Edit: Geert has noted that the Sequence Diagram should use instances, not classes, which is a fair comment. However the problem is the same: multiple lifelines would imply multiple instances, but in the question Method_A() and Method_B() are operating on the same instance, just from different threads. How can that be represented?
The approach I have decided to take is to add two lifelines for the same instance, then label one lifeline with the <<thread>> stereotype and add the thread it runs in to the name:
I realise this is probably not standard UML, but it seems to get across all the information I want to express in a clear manner, which is the most important thing, right?
Martin Fowler does mention a few times in his book that sometimes a non-normative diagram is actually clearer. So that's my excuse. :)
(Edit You can solve it by just using asynchronous messages as #sim points out. That will just do. The answer below is showing what is going on under the hood. So if you don't care about the details, go with that answer.)
You are asking more a design than an UML question. Namely, how do concurrent instances talk to each other. You said first
Method_A() is running in a thread and sits blocked waiting
which simply means that it can not accept anything since it is blocked. Now, guessing from the context of your question, I assume that you still want to communicate with that instance since
in different thread will then call Method_B()
So, in order to be able to accept a message the instance must be in an appropriate state. There are a couple of ways to achieve that. One simple is, if the according OS has support for that, to return to the scheduler and tell him that it's waiting for some message.
Now when method_b is being called you know inside Object1 that you are in some kind of idle state inside method_a and do appropriate (return-) action.
Another way would be to poll the scheduler for incoming messages and handle them.
You need to keep in mind that sending a message usually not directly deals with the instance but tells the system scheduler to interact with the appropriate instance (at least in most OSs).
I just remember from the Modula2 compiler I once wrote that it has a concept of coroutines which allows a concurrent thread to run within the compiled code. But basically that is just mapped to two independent threads running under the hood of a semi-single one and you'd depict that with two life-lines when going into detail.
N.B.: Rather than method it should be operation (since that is was is invoked by a message; while the method is what is implemented inside the operation). And as per common convention they should start with a lower case char.
And also: do NOT use classes in a SD. Unfortunately EA still allows that (why? Ask them!). Somewhere hidden in their docs there is a sentence that you must use instances. Else the model will break. A SD is always (!) a sample sequence of instances talking to each other. Classes do not talk, they are just blueprints for the instances.
You should never use classes in sequence diagrams, but instead use instances/lifelines that have your class as classifier.
If you hold the control down when dragging a class to a sequence diagram you can choose to drop is as instance instead of as class.
This way you can add as many as you want for the same class.
The notation you are looking for is an asynchronous message. You could theoretically express this using a single lifeline. But this wouldn't be readable. So a possibility would be having two instances of a threadclass in your class and show the interaction between the instances. But never show classes in a sequence diagram.
But why are you using a sequence diagram at all? For such internal behavour an activity diagram is most likely more appropriate. There you can use send and receive messages elements to express such a behavour per thread. Or if it shall be shown in one diagram, you can use fork.
In UML Sequence Diagrams you have the combined fragment type Alt to branch based on different values for parameters. But let's say that in the middle of your sequence you are waiting for one of two different messages from two different external actors and you shall branch the code depending on which one arrives, what would be the best way to model this? And to make the question a little more challenging, let's throw in the possibility that neither message comes (triggering a timeout).
Without a better solution, I would divide the sequence diagram into multiple sequence diagrams, each new one starting with the one of the two possible messages. Or possibly just go over to state machines. But is their a not too convoluted way that would allow me to show these different cases within one sequence diagram?
I would simply go for the two SDs which you can name accordingly. One should always keep in mind that a SD shall highlight a certain aspect of a complex chain of actions in a system. Trying to put more and more information in a single SD will mess it up and hinder more than it helps.
It is also possible to use diagram fragments which allows navigation through zooming into the two fragments.
The timing diagram will not really help here. You would still need a large alt-fragment to show the sequences depending on which message arrived first.
In addition to the answer I referred in the comment, I made a little sample with a duration constraint for the timeout.
If you have a lot of conditional logic to show Activity Diagrams are an alternative. They do not have object responsibilities or a time axis, but because of this they can freely use two dimensions to show flow control.
How to model - in a UML diagram or similar semi-formal way - an iTunes-like application that synchronizes directory contents. I want to show which data set is the master, and which are the copies that depend on it, which part of the data is always fully synchronized and what may be not fully-synchronized at any given time etc.
use at least two types of diagram. Define classes which interacts within synchronization process .. Directory etc. And use sequence diagram to model interaction (how instances exchange messages and data). Data which are synchronized add to messages as arguments. You can define timing of synchronization using time constraints or by defining initializing time of synchronization process.
I need to know this differences in order to undestand how to use them right.
Which are the differences of DFD and Activity diagram?
Actually, it's reasonably logical. You only have to look at the names.
In data flow diagrams, the lines between "boxes" represent data that flows between components of a system. Because these only show the flow of data, they do not give an indication of sequencing.
In activity diagrams, those lines are simply transitions between activities and do not represent data flow at all. They more represent the sequencing of activities and decisions. You can tell from these what order things happen in.
That's a simplistic explanation but should be a good starting point. Further information can be garnered from Wikipedia for DFDs and activity diagrams.
Explicit bias: I'm a DFDs proponent.
#John is correct that Activity diagrams can be used to represent object flow. #pax equally correct they seldom are.
Two big DFD advantages for me:
Link to object model. Data stores on a DFD provide a really nice way to link the data produced / consumed to the object model. Very useful for consistency and ensuring your thinking is joined up.
They de-emphasise control flow. Far too often designs over-constrain sequencing. Activity diagrams do support concurrency - but it requires the user to (a) remember and (b) use it. So the default is over-serialisation. DFDs don't. They lay bare the real sequence dependencies without any extra effort on the part of the user. Consequently they also make it easier to see causal relationships. If processes a and b both require data input D then it's obvious on the diagram. And hence parallel activity is obvious.
Don't get me wrong - I'm not against Activity diags. Where control flow is the primary consideration I'll use an AD over a DFD. But empirically I'd say I find DFDs a more useful tool in ~70-80% of cases.
Of course, YMMV.
Just a humble opinion from someone who has had to explain processes, both computer and manual, to upper management and CIOs. I have found simple is better and pound-for-pound, DFDs get the message across when I am actually "asked" about details. That being said, the better approach is to always practice the story line and answer in simple answers.
One final comment regarding the age of tools and products. Remember that in most cases these are running the business and work pretty darn good. The adage "you break it (or replace it) and you own it" can make you a hero or make you into a clown.
We have a CIO who wants to replace all mainframe application for the simple reason that they are old technology. One must weigh the consequences and understand if the replacement can handle workload. Have you ever wondered why JPMC, Credit Swiss, Walmart, and Bank of America to name a few still run mainframes?
My apologies for taking it in that direction. Just make sure, whatever analysis tool is used, that all aspects of the replacement are documented including workload, I/O, concurrent users, adoption curve, and scalability.
Data Flow represents flow within one module or one independent code. However Sequence Diagram represents sequence of activity in between different modules.
Yes at some points they may pass the same messages.
I basically use Sequence diagram in interface documents which will be shared with other modules/elements, however DFD will be used in Low level design documents which will be used to develop the code within one module or network element.
If we look closer to a dataflow diagram, we can notice that when a node collects data from all its edges, it starts to process them. And to process, it needs an activity token, which represents access to a processor. Usually the process of obtaining that token is omitted, but it has to exist. Typically, the whole node as a token is put in a double-ended queue, where on the other end of that queue free activities (processors or threads) are stored. A thread pool is a perfect example of such a queue, and the nodes ready to work are represented as tasks. As soon as a node meets activity, they both are taken from the queue and actual processing starts. When processing finishes, activity is returned to the queue. This way we can think of activity as a special kind of token.
So both dataflow and activity diagrams are just simplified variants of a general active-data-flow diagram, with either activities or data tokens omitted. But generally, both kinds of tokens can be represented in a diagram simultaneously.
Programmers used to think about threads as activities, but if we look at them closer, we notice that when a thread is ready to execute, it gets in a line to processors, and real execution starts only when a free processor switch to that thread. This is absolute analogy as tasks are executed on a thread pool. So from simplified point of view, a thread is an activity, and from more rigorous point of view a thread is a data token and the only real activity is a physical processor. This shows that activity tokens are not different from data tokens. And indeed, we can omit the route of node chasing an activity and consider a dataflow node as an activity itself, which starts to work immediately when all its edges (inputs) contain data.