I have a few classes on my UML diagram which should not be used, but still available.
Is there any way to mark these classes as obsolete?
I've seen <> notation somewhere, but can not find how to use it in MS Visio 2003.
And another question. Should these classes be on UML diagram at all? I can imagine answer on this question would be on "per case" basis, but I'm interested in hearing general opinions. And if you put obsolete classes on your UML diagrams, why you did it? or why not?
Thanks!
It's not clear to me what you mean by " should not be used, but still available.". If they need to stay in the diagram but you want to visualize that they are now obsolete you can create a new stereotype <> and use it to annotate the obsolete classes.
If you don't really need them in the diagram then use a version control system for models as duffymo suggested. A list of version control tools for modeling elements can be founde here
I think if you're going to take the time to update the UML, the best idea is to remove it from the model. Leaving a bunch of "obsolete" diagram elements hanging around makes as much sense as keeping commented code in a version control system. Let the version control system manage the history.
I think that your model should include all your project and then you extract views from your model. If a class is not having any value in a specific view then this class should be removed from your class diagram view diagram but not from your model.
If you want to keep this class in your diagram then you can add a small comment (usually yellow square) or change the color of the class. I usually use green for class and then change the color to grey/green almost invisible but still visible color for non strategic classes.
Hope this help.
Related
I have a C project. It has been imported to Rhapsody 8.2.
Now I want to generate:
Component diagram.
Structural diagram.
Dataflow.
UML
SystemC
How to do that?
Thanks in advance
Amnon
You can add a self-populating Object Model Diagram by ticking the 'Populate Diagram' tick box when you create it, then selecting the packages/classes to include.
I think the others will have to be created and populated manually.
You have imported a 'C' program. I think you have used "Reverse Engineering" to do that.
As already mentioned in one of the answers: C is not OO so you have little chance to derive the information that you want to generate simply because that information is not in your your source code.
You have probably already noticed that there will be no Classes with attributes and operations in your model, just files with variables and functions.
I'm always surprised to see people's expectations to reverse engineering... RE is a so-called GIGO process: Garbage in- Garbage out. Don't listen to sales people that tell you that there are tools that can automatically document your code afterwards: There is no such thing possible.
Component diagram. - Have to made by Hand
Structural diagram. - you can right click on a function and choose "populate flowchart"
Dataflow. - There is no Dataflow diagram in UML
UML. - As already said, there is not enough information in your source code to convert your C to a readable UML diagram
SystemC - You have to add a lot of information to create System-C, as already stated above, please contact Sodius in France or the US, they can provide you with more information.
W.
Is it bad practice for lines between different classes to cross in a UML diagram? Is it a design smell? Does it indicate that your classes are too tangled or independent or anything? Is it always/generally unavoidable? Or am I overthinking this?
Here is my current UML diagram if interested. You will see that I routed a couple lines all the way around to avoid overlapping....
Is it bad practice for lines between different classes to cross
Yes, because it can impede understanding of the graph/diagram.
Is it always/generally unavoidable
Not all graphs are planar (see planarity testing), so sometimes it is unavoidable.
But the problem is not as simple as "I will just route the line around". There are many rules and recommendations that constitute a good layout or contribute to good visual aesthetics; to name just a few:
lines crossing (you might have seen in some diagrams a small bridge when lines are crossing)
number of line bends
total line length
hierarchy (typically inheritance lines should be drawn upwards)
You can already see that some of the rules are competing; so layouting is always a balancing act. If you are interested in more detail I suggest googling around for "graph aesthetics" or "automatic (graph) layouting".
Unfortunately most research papers I have are behind paywall, so I cannot link to the pdfs, but some of it can be google-able; e.g. UML Diagram Layouting: the State of the Art or Aesthetics of Class Diagrams
In my opinion, line crossings may be unavoidable, but often, it happens when I am trying to show too many things with a single diagram. I see this as a "communication" smell rather than as a design smell.
I often found that explicitly writing down the question I am trying to answer helps spot the model elements that are not strictly necessary and that I should omit. Besides, several diagrams may better convey an idea/design than a single saturated one.
In your example, you could maybe break down your diagram following the colored areas you already identified.
When ever there are crossing lines, it is a good time to stop and think if the diagram has grown to be too complex.
I feel your diagram is trying to be abstract and concrete at the same time. I see it as being too complex. It is abstract in the sense that it provides an architectural overview, and concrete in that it shows structural detail related to implementation.
Personally, I might split your diagram into a component diagram; then express each component's structure using separate class diagrams.
I am new to UML designing and read few articles on this. bit confused where to start..
Do i need to prepare all of the UML diagrams for a web application or is some diagrams are only essential for an application.
Thanks,
Start from Use Case - define, who will use your application(actors) and what they will do with it(use cases). Also, join close use cases into subsystems.
Component diagram - what main parts the system has and what info they will send to each other and if some part belongs to another
Go on with State machine - define what states will have your components and on what reasons can they change they states to other ones.
Deployment diagram will define on what PCs will these components live and about the connections/protocols/interfaces between them
Plan your user interfaces - now only the set of pages and frames and navigation between them and commands on them. Do not solve placing and colors yet
Class diagrams for every component
If for for some of your classes some instances are specifically important, use object diagram.
Draw the look of the UI
Code.
UML is there to help you. Pick only what you need. You'll hardly ever need all diagram types. Plus, it is convenient for the reader if he needs to know only a predefined UML subset to understand your draft.
I'm a total rookie in UML and modelling. I'm learning some framework, and I'm trying to grasp and outline its key aspects. I've decided to do it with UML. But the problem is, the whole structural diagram of the framework is of no use to me, because classes have a lot of properties and methods, and there's a lot of classes.
What I need is a series of structural diagrams, each of which shows some specific aspect of the framework. And the classes involved should display only those attributes/operations that are of certain value to this specific aspect.
Does UML (as a standard) supports this on some level, and is there some tool that allows to do just that? I've tried Visio 2007 and Enterprise Architect, but I didn't found out the way to do what I need.
Thanks in advance.
What your are looking for seems to be able to customize views of your model and not to visualize the full class diagram. This concept is developed by Omondo which provides customizable views of your model by drag and drop. You can create as many views as needed, each could be different from the others while just using the same model element. This also the metamodeling approach for me where the model is not the diagram but the metamodel on which your build your graphical model.
If you don't need attributes/methods then you can try to click directly on attributes and methods keeping the ctrl button pressed, then you should be able to find a menu in the class diagram to hide them. The traditional menu is Hide from diagram.
This is what I do and it works really well.
You can also just click directly on attributes and methods but I don't see any documentation on this subject. It seems that nobody knows except the developer and myself about this option but this is my favorite one :-)
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.