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 :-)
Related
When browsing through a large UML class diagram (20+ classes), if I try to find the "path" from one entity to another or the connections of a certain entity, I get lost very easily. Are there any tools that allow hiding certain entities? Or that highlight paths or connections? So far I've tried ArgoUML and MagicDraw but they don't seem to have any of these.
Modelus Suite Model Designer has functionality that allows you to see references of selected element and connections as well. It is simple navigation, but usable for models of any complexity I would say. It does not highlight it, but it is possible to locate related elements in project tree or on diagrams.
You can find more info on the web side. Here is a link Modelus Suite
Hiding elements to split complex models into several diagrams is a basic (must have) feature for UML tools. GenMyModel is natively supporting such operation using "hide" from the popup menu.
(see: use model elements in multiple diagrams and demo video)
All UML tools should allow you to remove model elements from a diagram without deleting them from the model itself. The reason is that, in UML, a model is not the same thing as a diagram. A UML diagram is one of many possible views showing and hiding different parts of a UML model. A UML model instantiates elements of the UML meta-model, in memory and on disk.
There is a fundamental difference between a mere drawing program and a UML modeling tool. A drawing program (like MS Powerpoint or Visio) just draws pictures. A UML tool has an underlying meta-model that can render its instances on any number of diagrams. All true UML modeling tools will therefore allow you to remove model elements from a diagram.
Your claim that MagicDraw does not allow hiding elements on a diagram is untrue. Not only can MagicDraw hide model elements, it has a special "Relation Map" diagram that allows you to swim around in a model.
Is it possible to somehow organize my diagrams in Enterprise Architect? We're starting having too many of them, with each diagram containing many elements. Is creating a separate folder for each diagram the only solution to make the model easier to see through, or is there a more elegant layout for that?
In the first place, Model Views will help you to create distinct viewpoints representing your entities from different perspectives.
If you stick to the architecture principles of loose coupling and modularity, you should be able to split up very big diagrams into smaller ones. After all, their role is to give you an idea of how things are coupled and work together, but also to abstract from things that are not really relevant in the given context of the diagram. Diagrams are not meant to just visualize all elements in one big picture.
You can create package structures that are pretty complex and then use the model search. You can also put hyperlink elements for easier navigation between diagrams.
If you have to split up elements into different diagrams (which then go into different packages) EA will preserve their relationships and you can review them at any time using the traceability view.
I would also have a look at the EA options for composite diagrams. This should help you re-organise a Single System into a number of Composite Sub-Systems.
To start modeling an application architecture, you can use a perspective based approach or a view modeling perspectives approach to describe your system. For example use the 4+1 view based approach to collect your Logical, Development, NonFunctional and Requirements perspective. Organize it according the mentioned dimmensions or decompose each dimmension by the application modules and have a conceptual view to have a global view of your system.
To start with a model of an enteprise architecture use for example the togaf dimensions or zachman framework layers and dimmensions
You can use several packages to categorize your content.
I use to make a package diagram on top level which dynamically updates its contents depending on underlying packages (simply drag & drop the packages in the package diagram)
and the content (e.g. for activity diagrams) like entry or final can be saved in a common package.
Unfortunately there is no possibility yet (version 10 build 1004) to customize the packages e.g. with colors. So that a common packages could have a distinct color.
What I do to make Project Browser more organized is to create one package named "Diagram's elements" and drag all the diagram element there.
There's some good advice in this blog on the Sparx Systems (the EA publisher) website.
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.
Can anyone tell which UML diagram I should change if there is a slight change in the design of application.
The change is -> Earlier the application was using Active directory for authentication now I want to use the Membership provider instead.
I want to keep the change minimum in diagrams.
Thanks
Sounds like component diagrams or class diagrams. Check out the following topics and illustrations for VS 2010 Ultimate RC:
UML Component Diagrams: Reference at http://msdn.microsoft.com/en-us/library/dd409390%28VS.100%29.aspx:
A component diagram shows the parts of a design for a software system. A component diagram helps you
visualize the high-level structure of the system and the service behavior that those pieces provide
and consume through interfaces.
UML Class Diagrams: Reference at http://msdn.microsoft.com/en-us/library/dd409437%28VS.100%29.aspx
A UML class diagram describes the object and information structures used by your application, both
internally and in communication with its users. It describes the information without reference to any
particular implementation.
It will surely depend the diagrams at your disposal. Sound like a correction in one of the static diagram types, like the component diagram ...
This of course depends on how you structure your documents and your uml-diagrams.
In general I have a Conceptual model, Class Diagram and a Design Diagram which are diractly linked to the architecture. And then you should in most cases have System Sequence Diagrams and more. However, depending on how your structure is and to minimize the "changes" required.
I would suggest that you use something more generic for the parts that might be changed. Active Directory Authentication and Membership Provider Authentication is both Authentication methods, which means that you can, instead of displaying the whole sequence at the Authentication step, just use "Authentication".
Now, in the conceptual models and in the design + class diagrams, you will need to change and add some fields, tables or whatever is added. But it shouldn't matter if you need to add more or less, because the documents need to reflect upon your software as accurate as possible.
So, to minimize changes, use more generic types.
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.