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.
Related
I was given a special task to learn and discuss about UML at work. I have a little background about the topic, though I'm not sure what area should I give more priority since UML has now multiple versions. Should I stick with the the UML first version and give an overview for the UML 2 instead? or should I focus more on the UML 2 since it's the latest version? I'm confuse since I'm not familiar with the difference of the two versions.
I need advise regarding the matter. Thank you in advance. Pardon if this question is irrelevant in this site.
It might be practically difficult to restrain to UML 1 just for the following reason: Nearly all available tools for drawing diagrams implement UML 2 since long time ago. So, each time when drawing some construct, you would manually have to check whether it was already available in UML 1.
The step from 1 to 2 was in a large part motivated by the software engineering hype named MDA (Model Driven Architecture) some 10..15 years ago. This was about generating software directly from the model. To support this, all model elements got defined via some formal semantics. Also, some model and diagram types got enhanced. Sequence diagrams were enriched to control structures to express control flows. Component and deployment diagrams got enhanced.
Now, apart from suggesting that it won't make much sense to go back to UML 1, I read from your question that you need to set priorities. That makes sense, as the definition of UML (1 as well as) 2 is quite lengthy, and you don't want to study every detail of it. So here are a few hints:
With object oriented technology everywhere around, class modeling is the central notion. So you should be familiar with classes, associations, aggregations, composition, inheritance, attributes, operations and their parameters and results, visibility of methods and attributes, abstract classes and methods, and interfaces.
Objects of a class change their states by application of their operations. A central, and sometime underestimated, type of model therefore is state modeling. Here, UML offers two partly redundant model and diagram types: State and activity models. You should get familiar with at least one of them -- switching to the other should then be not too difficult.
Most users of UML are quite fond of use case modeling. I'm not, as those use cases tend to lack either significance (if you constrain to naming use cases and actors) or structure (if you start documenting system data and functionality with your use cases). But the rest of the world will only accept you as an UML expert if you know them, so you won't be able to avoid them. Just before using them extensively, think about how to reach the DRY (don't repeat yourself) principle when describing a system via use cases.
I am trying describe the runtime behaviors of a system. The system is a desktop application written mostly in Java. It is composed of multiple threads communicating with each other in the background and a GUI for user interaction.
I can draw some informal illustrations. But it's better to take a formal approach. Please advise. Thanks.
Update 1
Just found this 4+1 architectural view model. Seems helpful.
If you're looking for a UML approach, you'll want to look at an Activity diagram. (If your system encompasses multiple use cases, use one activity diagram for each.) If you want to diagram each behavior separately, use sequence diagrams for each single thread of behavior. If you are more concerned with the different states that your behavior passes through, use Statechart diagrams.
I would like to know which diagram from those two should be created first when designing large IT system.
In every article I read about UML, the component diagram is mentioned as almost last.
I think that, when designing a larger system is better to divide it to smaller parts/modules on the component diagram and then for every component create a detailed class diagram. Is that correct?
How it look in practice from your experiences?
Do you know of any article/tutorial that shows from beginning to end, the design of system using UML?
There is no mandatory order for UML diagram design - in fact, you will often find yourself creating several simple diagrams of different types, and refining them later. The process is generally iterative but doesn't have a follow a particular order.
That being said, some UML diagrams provide a more abstract view than others, and it may sometimes make sense to start with the most abstract views and work your way down to the most specialised ones. Use case diagrams typically come early, while object diagrams or state diagrams often come later in the design process, once the original, abstract solution has been refined.
You will also want to take a look at consistency between your diagrams: indeed, with several views you will introduce redundant elements, and it is important to make sure that they do not contradict each other. For example, if you have a sequence diagram and a class diagram, any call message in the former should correspond to an operation in the latter. See Alexander Egyed et al's work for automated consistency management and correction in UML models.
Back in the Dark Ages (mid-1980s), I used Data Flow Diagrams from Structured Analysis a fair amount, and found them very useful.
My current employer loves UML. I normally use BOUML, which doesn't do non-UML drawings.
What is the UML drawing that corresponds to the Data Flow Diagram?
If there isn't one, what is the recommended UML diagram to present the corresponding data?
Probably the closest thing is the activity diagram. It's not quite the same; more influenced by flow chart than dfd. However: you can do some of the useful things in DFDs, e.g. ADs do support concurrency and differentiate control flow from dataflow.
More details on comparisons & differences in this question.
[fwiw, I still use DFDs: they're simpler and more elegant in many circumstances]
hth.
UML 2 has a very good analogue to a data flow diagram:
the "information flow diagram".
Information flow diagrams are explained here:
https://web.archive.org/web/20121118061853/http://www.uml-diagrams.org/information-flow-diagrams.html
Note that UML 2.5 has information flows and information items, but the term "information flow diagram" is not part of official UML 2.5 diagram taxonomy. So formally, you just create a class or component diagram with lots of information flows in it to obtain your "information flow diagram".
I do this all the time, using information items of UML to represent my data.
There is no equivalent model in OOD. The emphasis on DFD's is data separated from the function. This is most helpful when dealing in a procedural way. DFD's scale much better than OOD, if you try to scale out (to the world view) using OOD you end up using Use Case diagrams, which are useful for capturing essences. I loved DFD's they are so high level, and yet can be expanded by opening up a DFD box and calling it level 1 etc.
I am currently in the process of learning the Go programming language, this does not use Objects whatsoever and in some respects I feel that DFD modelling would suit it much better.
I too am looking for a diagram that could do this sort of work. In Go structs are used intensively which are basic data types. You can have a primitive extension method attached to it which resembles OO but in fact if you look at the Assembly code it appears to be syntax sugar for a function, who's first parameter is the struct you wish the function to operate on.
My advice, is that if you're doing OO code, then use OOD. They map better, and do help in the thinking about a system. It takes a while to get your head out of Procedural code, especially if you're coming from programming from the 80's/90's. Once you're in the zone with thinking about objects then the OOD methods work fine. Its not strictly a methodology as there is no straight answer to which parts you use, just thinking in objects I find to be the hardest part. A good book on this is "Object Thinking--David West"...it helps to think about objects first. Once you start its very difficult to stop, you may even like some end up getting trapped in the kingdom of the nouns which is a horrible place to be, because you write endless boiler plate code, just so that the system is described perfectly. This is a form of coding hell which I have stayed clear of for many years.
If you are coding in a language that allows procedural code, or even mixed OO/Procedural, you need to decide your paradigm before you start coding, for example in both Python and Object Pascal (Delphi) you can go either route of OO or procedural coding mixing the code up into a mess of paradigms. This will decide which diagramming tools that should be used, and how you are going to analyze the system.
Recently there have been shifts in Java and c# to provide functional programming techniques. These I have discovered don't fall into either category of programming (OO or procedural). Trying to map functional programming code into an object is a nightmare.
I am sorry I haven't provided an answer, but it depends on what code you are writing.
There is no direct analogue, since UML emphasises OO design wheras DFD comes from structured systems analysis and design (SSAD). In UML a number of diagrams, specifically those in the with interaction diagrams group have characteristics that might model elements of data flow and processing. A Communication Diagram can be used to reflect most aspects of a DFD in general, while a sequence diagram may model specific sequences of flow. If you wanted to suggest DFD semantics then you could use stereotyped objects for data process and data store, and use actors for external entities.
It may be worth noting that Sparx Systems Enterprise Architect, while primarily a UML tool includes DFD as an extension.
Similar diagrams would be:
information flow diagram
communication diagram
sequence diagram
Theoretically, new diagram kinds can be defined in UML, optionally extending of one or more conventional diagram kinds. The canonical diagram kinds defined in UML are essentially defined as a part of the UML metamodel itself.
Formally, a definition of the UML metamodel is provided in the UML specification published by the Object Management Group (OMG), as well as the corresponding meta-metamodel defined of MOF - to which there is also a corresponding specification - moreover as accompanied with the formal OCL specification, as with regards to definitions of constraints in UML models in applications of the OCL language in UML - and then there's the XMI specification, as with regards to specifications for how UML models may be stored in machine-readable format.
Ostensibly, all of these specifications may be combined for application as though "Under the hood" of any single framework for UML modeling - whether in applications of the Ecore subset of the UML metmodel, or in canonical UML.
Reviewing a short academic presentation about Data Flow Diagrams -although somewhat in departing from formal definitions of UML diagram kinds, but nonetheless in a broader context of applications of the MOF meta-metamodel - perhaps the canonical BPMN metamodel - in its conventional, graphical abstract syntax - perhaps BPMN may serve to provide something of an analogy to Data Flow Diagrams?
Of course, modeling practices may vary by vendor and by application environment.
I consider a Data Flow Diagram as a Sequence Diagram, with Data Producers and Data Consumers creating, using and destroying Data objects by means of synchronous and/or asynchronous messages.
I use Enterprise Architect 'Dynamic View' Analysis diagram.
Control = Process
Information = Data Store
In many ways their Analysis diagram is much better than a data flow diagram, as you can also show events in the form of sending and receiving and there is a process symbol too but I prefer Control. It includes object and decision.
I had some questions regarding the structure and behavior of a model, using UML, and the relationship between the two :
Did you find any limitations for UML regarding the specification or understanding of the relationship between structure and behavior?
I was wondering if you have any practical ideas of how one can optimize the relationship between structure and behavior, using UML.
Do you know any UML tools that help understand better this relationship or represent it much easier?
Thanks
Yes:
A sequence diagram is readable at a high level, showing how a transaction involves a few components; but it's not good (not readable) at the detailed level, showing how a transaction involves dozens of methods (method A calls method B, which gets data from methods D and E, and then invokes method F, etc.).
Looking at a class diagram, you might see a based class with several subclasses; this tells you nearly nothing about the behaviour of the classes (it only tells you that they may have some behaviour in common, or at least a common API, plus some individual behaior that's unique to each subclass).
That's a big question. A quick answer is, "Attach text notes to the objects: diagrams aren't sufficient without descriptive text."
No, I don't really; a UML tool help you create UML diagrams (and generate code from the diagrams), but it's up to you how you use it. There was a neat product described in the book titled Real-Time Object-Oriented Modeling (1994) which was an executable model, i.e. the model itself had behaviour, but I know of no UML tool quite like that. The closest I know of is being able to "round trip" between the model and code (i.e. generate code from the model, and the model from code).
Sounds like a homework problem. Wiki can tell you all about UML.
The limitations of UML are the same as any form of communication. The simpler your language, the fewer things you can communicate and the clearer your communications will become. A shape like a square or circle identifies a structure, a line indicates relationship, an arrow indicates movement, or flow. You could enhance this by defining the meaning of other properties, like direction, boldness, color, number count, different shapes. You could incorporate multimedia layers like audio or video, motion, tooltips- but now we're not talking about UML anymore.
My favorite UML tools are a whiteboard and some dry erase markers.
I think that things have changed, regarding UML's usefulness to melculetz.
In Visual Studio 2010, I can define an association relationship, that will generate composite classes. I can specify the multiplicity and class qualifiers. I can also generate classes from the model.
Presently, I am attempting to visually model the phases of a system, in order to visually define the methods for a state-machine object. That is my attempt to integrate structure and behaviour. Check my blog to see how I get on.
Class Analyser visually expresses the behaviour of class objects. Limitation removed.
I think that the answer is to turn your development methods towards MDA. You will generate more classes, but the payoff is in terms of manageability and re-use (where you template your efforts).
I am still working through my model but, I find VS2010 promises good tools for managing the development process. I have yet to investigate UI modelling, but have heard the rumours. I may have it all wrong but I think that, by working with Lightswitch, I may be able to model the UI also.
UML allows you to specify the signature of a method, and group methods into classes, but it says nothing at all about what code you use as implementation. If that's what you mean by "behavior", I don't think UML addresses it at all at the class level.
It's even worse at the UI level. My impression of UML is that it's woefully inadequate for specifying UIs.
I think the effort required to embed everything into UML is greater than or equal to coding the application, with the added burdens of UML tools being poor IDEs and inability to prove correctness of UML the way you can with unit testing.
UML is way oversold, IMO. I consider it a convenient notation for informal communication between developers, nothing more. It has never been and never will be the object oriented equivalent of engineering drawings.