I usually document system architectures with traditional UML class diagrams, and then further document the most important/complex code paths with arrows from one method to another, and which property it updates, etc. Usually with little notes of the arguments used and values set.
something like (horrible ascii art warning)
--------------
CASE X | main class | -----------------
-------------- | util |
| count |<-+1 -----------------
-------------- | -----------------
user ---x=A-->| doStuff(x) | ---y=Z---<>| someMath(x,y) |
| other() | -----------------
--------------
is there a name for such a thing? note how i'm pointing to individual methods/properties, not to whole classes as a traditional UML diagram would.
I use graphviz/dot for all my other graphs. but i can easily move to something else that allows me to do that... i just rather it be programatical like graphviz, not a drawing tool like visio if possible.
Please, feel free to edit to add tags if you think some other graph engine may provide this.
No, there is no name for such thing in the UML world. Although in UML you can draw diagrams combining various drawing elements nearly at will and thus producing a new inventions it, your drawing does not fall into the UML standard.
A very big advantage of using standard is that other people can understand what you mean without the need to provide them some reading instructions.
In UML there is whole set of "traditional UML diagrams" categorized as "Behavior Diagram". You may want to go through the examples in Kirill Fakhroutdinov's online book http://www.uml-diagrams.org/index-examples.html
UML Sequence Diagram (in your case) seems to be the first thing to play with.
In UML using drawing tools to produce some picture may be the poor-man's choice, but you'd have to study hard to make sure that you put the picture right.
Instead of using a picture drawing tools, we rather use UML Modeling tools which support the drawing-right and they sort of "know" what the picture shows and can generate code from the UML model (e.g. hierarchical state machines) or can reverse engineer a source code into an UML model.
Furthermore the UML model format was standardized as XML Metadata Interchange (*.XMI) and once you have model in this format you can use various tools to round-trip and produce artifacts (generated documentation, generated code, ...) that you need
As xmojmr has said, you ought to look at sequence diagrams. UML breaks itself into structural and behavioral diagrams. You probably shouldn't add behavioral elements into a structural diagram (which is what you are doing). Your explanation of why you are doing what you are doing is exactly the sort of explanation that people give for the use of sequence diagrams: they're a way of documenting paths through your code.
You'll also find that they are used to document paths through use cases (a "use case scenario" is a path through a use case), so keep in mind that class diagrams represent the structure of use cases. In other words, they all go together, but you're likely to see a lot of sequence diagrams that have been worked out from use cases rather than class diagrams. I wanted to point this out so you don't get confused by the apparent orientation of sequence diagrams and use case diagrams.
Related
I am working on a data science project for my 3-2 mini project. My project analyzes the performance of a country in the Olympics based on some attributes. But I am confused about the UML diagrams I should be using in my project.
There are some 15 UML diagram types out there. A sensible sequence of diagrams to be created depends on your approach.
If you'd like to create an analysis model that is a conceptual model of your problem domain then a sensible sequence of diagrams might be:
Usecase diagrams
Activity diagrams
Class diagrams
and if your project gets bigger you might need package diagrams.
If you'd like to create a design model that is a conceptual model of your solution domain then a sensible sequence of diagrams might be:
1. Component diagrams
2. Class diagrams
3. Sequence diagrams
4. Statecharts
In both cases a starting point is having a diagram for your system context. Some people like to mix component and usecase diagram features to denote a system context.
The aspects you might want to take into concideration of your diagram choices are:
syntax - how strictly would you like to follow the UML standard and what use does adhering to the standard have for you
semantics - what is your need - what do you want to document - and who needs to understand it
pragmatics - what is the best way to achieve your projects goal e.g. being efficient and effective
tool - what tools do you have at hand and are used and known to your peers - what can you afford to invest in keeping the tool infrastructure up
While your question is very broad, I could imagine that in view of:
My project analyzes the performance of a country in the Olympics based on some attributes.
you'll certainly need a class-diagram. Because the class diagram will clarify what kind of objects your software will manipulate (e.g. Olympic game, Participating countries, Teams, Athletes, Discipline, Competition), how they are related, and what attributes are associated with which each.
This will enable you to determine for the different analysis you want the access path to the relevant attributes. It will also allow you to find missing attributes, and to desing a convenient interface for the different classes.
You may also use other diagrams. But with the few requirements you've shared, it's difficult to guess which one and I do not want to do a lot of guesses. I could nevertheless imagine that a use-case diagram could help to give the big picture of who is going to do what with your software.
I'm learning software engineering at school and right now we're focusing on data diagrams. That is, Objec Classes, associations (and multiplicities), Ternary (or in general N-ary) assocciations, aggregation classes and so on.
I've been taught that we are using the UML standard, but as far as I can see, most UML editors I've found don't even support (or do it very poorly) the UML concepts I am using, I find myself using text labels all over the diagram to express almost anything, and I can't even define an N-ary association properly. I can draw a diamond from the flow-chart drawing part and draw some arrows, then define multiplicities with labels, but I find that unprofessional.
So, I've got two questions: Is UML what I've been taught? Does it have a more specific name (I was told they were called data diagrams).
How can I check that I am using the correct tool and that it is really UML what I study?
n-ary associations are UML. But they are not so often used really. Most of associations are one-or two-directional binary ones.
DATA diagrams are NOT UML. But the standard allows to use class diagrams for showing tables and their relationships. If you use class diagrams, it is UML, if data diagrams, it is not.
Multiplicities are UML. You should define them as attributes of association.
As for arrows, UML standard allows not to show them. But of course, they should be again set as attributes of association.
It seems that you use diagramming tool without UML class diagrams support. And youu need rather a modelling tool. Try VP-UML - it has free community license, including all types of UML diagrams. Or if you can install Eclipse, it has many UML plugins. The largest are EMF or Papyrus. They are free. Green UML is for starters.
I understand your troubles - many "UML" courses do not teach real UML. Many widely used tools have errors in UML realization. Some of them (IBM) are very far from the standard. The best place to check if you are on the right way, is the OMG UML 2.5 standard. It is beta2, but the content is virtually equal to the current 2.4.1, and is more easy to understand. (the current change has merely to simplify the documentation)
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.
What's the difference between sequence diagrams and scenario diagrams in UML?
I think you mean System Sequence Diagram (SSD) and Sequence Diagram.
The purpose of SSD is to illustrate a particular use-case scenario in a visual format where the system appears as a black box.
Sequence Diagram, on the other hand, shows how system objects interact over time for achieving a particular scenario of a use-case.
"Scenarios" per your link aren't diagrams, they're narrative text. They're also called "Use Case Narratives" among other terms. They are approximately equivalent to other behaviour specifications (sequence diagrams, activity diagrams).
There are generally three differences:
Format. Scenarios are textual, sequence/activity diagrams are, well, diagrams
Content. Textual narrative is often used to describe the sequence of interactions between the user and the "system" in Use Case descriptions. Hence there are usually only two participants (User & System). In contrast, sequence diagrams are primarily used to show how behaviour is distributed among objects. Consequently there will usually be more than two participants.
Formality. Narratives are often used earlier in the cycle to get an idea of what's needed. Consequently they're often less formal than Sequence diagrams - which typically show inter-object messages ("method calls").
For examples of tools that do this, take a look at websequencediagrams.com. Or search for "free UML tools".
There is no diagram type called scenario. Maybe you are thinking of collaboration?
Sequence and collaboration diagrams are actually the same: the Sequence depicts the chronology while the Collaboration depicts the interactions between the collaborators. Together (a tool that was around a decade ago) used to let you literally just change the setting and see the diagram in the other mode.
I use OmniGraffle (Mac). It's great for class diagrams. Has support for Sequence diagrams but not Collaboration.
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.