I want to model an activity, where there can be two several initiating events. These events has two several responsible actors. Is it allowed that a UML activity-diagram could have two initiating events and only one end? Could the action-flow be joined?
I want to know if I defy against the UML-modeling principles, if I do this.
Would be nice, if there are some hints for me.
Greetings,
Martin
The UML 2.3 superstructure specification (p389) says:
An activity may have more than one initial node.
and
If an activity has more than one initial node, then invoking the activity starts multiple flows, one at each initial node.
So according to the UML spec you're not violating the rules.
That said, #Dave is on the money - the most important thing is your model makes sense to you and those who will consume it. The UML specification is so riddled with inconsistency and ambiguity that it's questionable what 'being compliant' even means.
So long as you and all users of the model have a common understanding of what it's representing then don't get hung up on the UML's pseudo-semantics.
(Of course, this assumes you're using the model as a picture for communication, not as a formal specification that will be interpreted/compiled to code. If so, you'll need to formalise your own semantics for what it means).
Related
I have this kind of situation where I have multiple actors which share the same use case.
I cannot figure out from which point of view I should write the flow of events and describe the sequence diagram of this specific use case, having more than one single actor.
You: I have multiple actors which share the same use case.
... from which point of view I should write the flow of events
Use-cases are goal-oriented. They are not supposed to be a functional decomposition nor a sequence of actions. It's not me, but Ivar Jacobson, the inventor of use-cases, in Use-Case 2.0:
A use case is all the ways of using a system to achieve a particular goal for a particular user. (Page 4)
So use-cases are meant to provide the big picture. Your use-case diagram should identify these independent goals. Of course, behind each use case, you have some narrative that describe the interaction between the actors and the use-case:
The purpose of a use-case narrative is to tell the story of how the system and its actors work together to achieve a particular goal. (...)
Use-case narratives can be developed at different levels of detail ranging from a simple outline, identifying the basic flow and the most important variants, through to a comprehensive, highly detailed specification(Page 47)
One way of describing this flow, is how Geert Bellekens explained in the comments: describing the scenario telling who does what in which order. A variant of this presentation is a tabular form: a column for the actor actions and a column for the actor actions.
Now, if you're at the beginning of the design, and especially if you have several actors, this kind of UC description forces you to make a decision about the way you design the interactions. A more creative variant is to describe essential use-cases: instead of describing the flow of event, you make a table describing mapping more in detail the intents (i.e. intentions) of the actors (in one or n columns) to the corresponding responsibilities of the system (in a separate column).
You can then start to think about possible sequences, but also about alternative sequences that could provide a better user experience or a more optimal flow of information. The flexibility is so high that you could even design voice-driven or NLP driven interfaces in which the sequence is not predetermined but could be different for each use-case execution.
I'd like to use UML to draw a high level diagram of my system's message driven architecture.
I am struggling to identify the correct diagram to draw a system of EIP microservices which exchange messages via message channels.
Which UML diagram is most appropriate for this?
When you say EIP, I assume you mean Enterprise Integration Patterns, I.e. a varied collection of patterns for enterprise application integration such as Message Router, Message Broker, Message Channel, Service Call and so on, as documented in several popular books and papers. If this is the case, then your reference to the Message Channel pattern makes sense and I think I understand what you mean.
The UML is a general-use language set, and can be used to represent many different aspects of your architecture, so the answer to your question depends on what you are attempting to show and at what level of abstraction. If your focus is on messaging (message timing, ordering and so on) then you need to use one the the behavioural languages within the UML; if you want to represent messages (structure, types, content etc) then you can do so with a structural language. The answer from 8bitjunkie suggests Communication Diagrams for the behavioural side, but you could also use Sequence Diagrams, Activity Diagrams and State Charts depending on your focus/need. Sequence Diagrams allow you to identify timing aspects more clearly than Communication Diagrams. For message structure I'd recommend Class Diagrams. The UML can also be extended through Tagged Values and Stereotypes to include much greater specificity and add structured detail if you would like; there is no real limit to the structured information you can capture in a UML model.
From the introduction of enterpriseintegrationpatterns.com:
The UML Profile for EAI [UMLEAI] enriches the semantics of
collaboration diagrams to describe message flows between components.
This notation is very useful as a precise visual description of a
system that can serve as the basis for code generation as part of a
model-driven architecture (MDA).
Collaboration diagrams are replaced in UML 2 with Communication Diagrams
However the introduction of enterpriseintegrationpatterns.com goes on to say:
We decided not to adopt this notation... {because} ...the UML
Profile does not capture all the patterns described in our pattern
language.
At the current time of writing (April 2019), it appears that the last time that the EAI profile for UML was published was March 2004. This predates the excerpts from enterpriseintegrationpatterns.com, which according to the way back machine was first published in August 2015.
This suggests that UML 2 is ill-equiped to describe message-driven system architectures which embody EIPs.
You can use a component diagram and/or a composite structure diagram. If, in your case, each microservice is instantiated only once, then you only need one of these diagrams. Otherwise, it would be good to have a component diagram show the class level and a composite structure diagram show the instance level. See question Component diagram dependency vs assembly.
A message queue can be modeled as a separate component with stereotype <<queue>>, or as an interface with stereotype <<queue>>. Modeling a queue as a separate component is the best choice if the queue is not owned by one service. However, if it is owned (only one service puts/publishes messages on it), then a separate queue-component clutters the diagram and it would be better to model it as an interface, provided by the message producer and required by the message consumers.
I'm a little confused about difference between state machine diagram and activity diagram in this specific situation.
In a follow simple schema, can you distinguish between activity or state machine diagram? The symbols are present in both diagrams.
thanks
Mauro
I now can confirm that you can't tell. On p. 331 of the UML 2.5 spec you find an example of the receive event used in a SM. The very same symbol is used on p. 409 for an AD.
So the answer is: no, you can't tell which diagram type is being used from the above example.
And more generally (from the Annex on p. 683):
NOTE. This taxonomy provides a logical organization for the various major kinds of diagrams. However, it does not preclude mixing different kinds of diagram types, as one might do when one combines structural and behavioral elements (e.g., showing a state machine nested inside an internal structure). Consequently, the boundaries between the various kinds of diagram types are not strictly enforced.
No, sometimes (like in a given example) you can't tell based only on shapes. However
usually you know upfront which diagram it is so it's not a problem actually
the names will be different. States will have nouns while actions/activities as behaviours are named with verbs
especially on SM usually there are other elements that make it distinguishable: events triggering, action within states (entry/do/exit), actions run on transitions, SM specific elements like history
while signal receipt/send signals are allowed in SM they are hardly ever used
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.
I'm fond of using UML diagrams to describe my software. In the majority of cases the diagrams are for my own use and I use them for more involved pieces of code, interactions etc. where I'll benefit from being able to look back over them in the future.
One thing I've found myself doing a few different ways is diagramming threads. Threads by their nature tend to pop up in the more involved pieces of code and keeping track of them is often a primary purpose of my design documents.
In the past I've used a symbol in a sequence diagram to show the creation of a new thread but looking back at some diagrams doing that it's sometimes ambiguous between an object's lifetime - which sequence diagrams are for - and a thread's lifetime. Is there a better approach for incorporating threads into UML?
I managed to produce a diagram that makes sense to me at the time of drawing it. The basic premise is that I've overlaid grey boxes representing class instances with blue boxes representing thread lifetimes. The main thing it lets me keep track of is knowing which thread I will be executing on when I call certain methods.
No doubt there's better and more intuitive ways to do thread and class modeling. The measure of success for me is whether my own diagram still gives me the same level of understanding 6 months down the track.
Activity, Sequence, and State Diagrams are all correct ways of showing thread behavior.
1st: (To vs's comments) There are two sets of diagrams or modeling elements in UML, static structure, as you put it, and behavioral. Any book will help you understand the split, typically in the contents/TOC, additionally it can be seen on page 11 of Martin Fowler's UML Distilled a near defacto standard for beginning UML in my opinion.
2nd: (To sipwiz's question and comment) Activity diagrams are not commonly understood to model business process, they can be used for that however, and most examples or simple tutorial would approach it from a business standpoint.
Discussion on your options to model threads:
Activity diagrams - Allows for forking and specifying concurrency by using a BAR and usage lines. Note the example at the bottom is no a business process, example. Most people can read these, business, management, and developers, though sometimes they can lack detail or get messy.
Sequence Interaction diagrams - In the same post, example, you will see sequence diagrams allow you to specify parallel behavior within a sequence by boxing parallelizable behavior with a label "par", this is useful to show the reader what methods can or should be called in parallel, ie, by different threads. This is the method I would use for detailed developer like discussions around building an object.
State diagram - The state chart just like the activity allows for concurrency by using a BAR and usage lines.
NOTE: These will not model a specific thread and it's exact lift cycle, as that is part of the instance/run-time level of modeling, if this what you want clarify your question and I will respond. I would just model it using one of the above as no one other than a MDA/UML expert will call you out, and you are not generating a running system.
Also: Please note that further details can be found in most UML books.
Also leveraged: http://www.jguru.com/faq/view.jsp?EID=56322
Traditionally threading has been depicted diagramatically using Petri Nets. Rob Martin has an article on multithreading in UML which you may find useful.
Update- just remembered you can represent threads with forks in activity diagrams- I've managed to find something that explains this.
It is very hard to find any free tutorials for Petri Nets, however I know Petri Nets are good for modeling concurrency, so I Google'd "producer-consumer Petri Nets" (my favourite threading thing) and found this.
I've also found some slides that show Petri Nets modeling a Semaphore.
UML activity diagrams have fork and join elements to show parallel flow of logic.
I don't know of a way, but using a sequence diagram does not seem entirely inappropriate, considering that a thread is in many languages implemented as a Thread (or similar) class.
The most UML-compatible way would probably be to add an annotation of some sort indicating that the 'object' represents a thread.
The UML is defined by the UML Superstructure, you can find it here http://www.omg.org/spec/UML.
If you read the specification you find that a UML class can be active. An Active Class is a class with the meta-attribute isActive set to true. It is also depicted differently.
An object instances of an active class automatically executes a "classifier behavior". As for any behavior you can define it by means of an activity in which you wait for asynchronous signals (AcceptEventActions) and invokes methods (CallOperationAction) or other behaviors (CallBehaviorActions). That is how active objects are modeled in UML. You just have to read the UML specification.
Activity diagrams will model the internal workings of your software with forks and joins to represent threads. To find out exactly how to model this properly, please see Conrad Bock's excellent series of articles. Here is the article that covers forks and joins, but you should follow the links back to the first article in the series to learn how to properly model using "Colored Petri Nets". It's not how you think (and it's pretty easy)!
There is a new, in-process standard at the OMG for a language called Alf that provides a more convenient surface notation for activity diagrams and is intended for representing code. From the spec:
A primary goal of an action language is to act as the surface notation for specifying executable
behaviors within a wider model that is primarily represented using the usual graphical notations of
UML. For example, this might include methods on the operations of classes or transition effect
behaviors on state machines.
For a programmer, you probably can't get more intuitive than Alf. And it will convert perfectly into UML activity diagrams.
UML strongest point is depicting the static structure. If you use short-lived threads, I also don't see any easy way of diagramming them. Maybe you can find a solution by turning things around a bit: why do you use/need threads? What's the functionality they provide? If they interact with each other and follow some (message passing) API, drawing them as components might make sense.