Here is a simple inheritance in UML :
I used to believe it was possible, with UML, to represent it in a "shorter" version, like this :
But the CASE tool I'm using right now does not allow me to use the latter. I checked the internet and various books I own and as I didn't find anything about it, I started to wonder if the "shorter" version is correct regarding the UML spécifications.
This has and is being used in Enterprise Architect. I searched in older UML specs but could not find any trace. The current UML 2.5 does not define that notation.
I think that it's a useful notation and asked Sparx to bring it on the agenda of OMG. But even if it does, OMG is very, very slow.
Related
I am trying to develop an OWL ontology based on different UML file resources presented in XMI format. Reading through the internet for a while now, it seems that almost all the available tools or approaches are outdated and even when trying some of them they don't provide the expected outcome.
Since this ontology plays a really important role in our project, I wanted to know what is the best approachs/tools to be used in order to convert UML to OWL ?
I have looked into this myself as well and I have found no tools that can do this satisfactory. Problems I ran into were either the tools used an old version of UML, did not support all UML features, used OWL 1 rather than OWL 2 and was supported by only an old version of Protege.
I resorted by doing the translation by hand, which for most UML constructs are not too difficult. For this purpose I have done a write-up on UML vs OWL, which gives an intuitive explanation for why some of the translation is done in a certain why, as well as provide a reference for translating UML to OWL.
There's an OMG spec now available at https://www.omg.org/spec/MOF2RDF/
I haven't yet found an open-source tool implementing this directly (i.e. convert from UML/XMI to OWL/RDF), but there are EMF related activities, that may be relevant (haven't tried), e.g.:
https://github.com/ghillairet/emftriple
You'll probably never get exactly what you want unless you do it by hand, as Henriette mentioned. One viable option is using COGS, which I've found to work pretty well.
The catch is that it's related to Rot's answer by supporting the OMG specification. If it's not much work to make sure that your UML conforms to that specification, it may save some time in the long run. Here's an example of an OWL file produced by COGS.
Please I need help in understanding this two approaches in the uml world. I am a programmer who is new to uml. I just started learning uml lately but kept getting this phrase asked all the time. - Are you modelling or drawing?. An explanation is needed with clear examples.
This link hinted just a little but I am stil confused -- http://modeling-languages.com/drawing-tools-vs-modeling-tools/
UML is a modeling language, which has a graphical notation. Its semantic is precisely specified by UML 2.5 standard of the OMG and also the international standards ISO 19505-1:2012 and 19505-2:2012 (although the latter corresponds to UML 2.4.1).
THere are two different approaches to UML diagramming. And it's heavily influenced by the tools you use:
Drawing tools generally offer UML shapes to be used in drawings. But there is no deeper meaning behind the shapes. It's only pictures. These tools would allow you to mix a use case with a class or an actor in a deployment diagram. The advantage is that you can do what you want. The inconvenience is that what you want may not be compliant.
Real modeling tools let you combine only valid UML elements together and ensure consistency of what you draw with the deeper meaning of the UML language. And they build a true and comprehensive model behind the scene by combining all the facets of the different diagrams.
Modeling tools can do smarter things. They can relate for example a class to their object instantiations in sequence diagram. They can help you to find all the other models in which a specific class is used. If you rename a class or add a property in one diagram, it'll be automatically reflected in all the others.
Modeling requires more discipline, but it's more powerful in the end. Some modelling tools can even use their understanding of UML to generate code out of the model.
You can use UML diagrams in very free way and you can use them up to the specifications. There are even different UML tools - some support only free style diagrams/drafts, some check dependencies and correctness and thus create models. There are some tools in between (MS Visio is one of them)
Nothing is ideal and fitting for everything. For example, some strict tools (VP and EA) forbid to make number-named classes, but according to UML specification you MUST use number names for anonymous classes. But -sigh- we have what we have.
Use of UML as such is not strictly predefined. So, you can use it for freehand drafts, later work on them more thoroughly and make them models. Or do only drafts. Or only models. But at any moment you should know how strictly are you keeping up to specifications. Or at least, trying to keep up. But even very free draft can help you greatly to understand the task or to think in a more productive way.
Although I found an article about OMTvs. UML I can't figure out the consequences of using OMT instead of UML- class diagram. What are the benefits of OMT compared to UML- class diagram? As far I know I can depict a class diagram in nearly the same way than this is done by using UML, or are there any known circumstances where only OMT is able to illustrate a specific context? And a bit more interesting question is, what are the criteria used to select between the two modeling tools?
To my knowledge nobody uses OMT anymore. It was superceded by UML; James Rumbaugh was principal in the development of both and a lot of OMT's concepts went straight into UML. So you'd be hard pressed to even find a tool that supports OMT today.
As to the selection criteria, there are two main ones when you choose any form of documentation: is it suitable for what you want to express, and will the audience understand it?
With UML, which is standardized by OMG and for which there are several tools available, the answer might (!) be Yes. With OMT, which is obsolete, it's most likely No.
In my object oriented programming class, we learned some of the main concepts of UML and I was just wondering if UML is common in real world situations or are there more popular methods.
There are certainly organizations that rely on UML, including a few that may expect you to answer OO design questions with UML in an interview. Plus, documentation tools like Doxygen generate UML-like diagrams to describe a class hierarchy.
Beyond that though, most groups I've worked with in academia or industry don't really use it. If you want an explanation of why, read "Death by UML Fever".
Generally agree with #chrisaycock. Would add a couple of things:
You should distinguish using UML for specification versus documentation. At the peak of its hype curve, UML was touted as the former. So development processes mandated modelling in UML before moving into code. That use has diminished greatly (although there are still pockets using executable uml, notably in real-time/embedded environments).
As a documentation tool, UML is still popular. UML class diagrams, for example, can convey the structure of a module in a way that is much more revealing and intuitive than linear code can ever be. Similarly sequence- or activity diagrams are very useful for understanding flow of control for an action that transcends a number of classes.
In the documentation context UML diagrams are increasingly being generated automatically rather than being manually created, e.g. from doxygen (as #chrisaycock mentions).
However it's also still useful for sketching out designs ahead of development e.g. on a whiteboard.
hth.
I once attended a Q&A session on UML and MDA in embedded systems where the panel included authors Bruce Powell Douglass and Steven Mellor. Having previously studied and worked on RT-SSADM projects and the Ward-Mellor methodology, I challenged Stephen Mellor on why a new way of software design comes along every 10 years before practitioners have hardly gotten to grips or truly understood the last one. He responded rather too honestly perhaps with "this way I sell more books"!
To some extent therefore I suggest that the hype surrounding any particular notation or methodology is driven primarily by CASE tool vendors and publishing houses; often the authors are also employed by the tool vendors and have titles like "Chief Evangelist".
That is not to say that these tools have no value; we should all be wary of such marketing, but on the other hand we also need to communicate our ideas and designs in an unambiguous and clear manner, and using a defined notation however inelegant, will always be better than some ad-hoc "sticks and boxes" notation that has no definitive semantics. Given that need for communication, UML (and derivatives such as SysML) is currently the most widely accepted and used notation, and currently enjoys the widest tool support. It differs from much that has gone before by being defined as a standard agreed by multiple parties rather the work on a single author or CASE tool vendor, so it is likely to develop rather than disappear.
I think the article, linked by #chrisaycock, could also have corollaries e.g., "Death by Agile Fever", "Death by CMM Fever", "Death by RT-SSADM Fever", ... ;-)
As #sfinnie stated, it really depends upon the usage, but UML by itself is nothing more than a notation. In order to be really useful, you need to follow some development method. #Clifford's post not withstanding, I'd recommend a mature method. Executable UML started as Shlaer-Mellor and has been in use for 19+ years. Douglass' method (not called ROPES anymore, but ???) has been around for 11 years. The Unified Process is based on Booch, OMT, and OOSE methods, so it can be considered 19+ years old as well. Of course you might find some other UML or non-UML development method that better fits your needs.
Visio 2003 uses UML 1.4, which means that some stereotypes from UML 2.0 simply don't exist, and they need to be modeled by freehand drawing (I may as well be using Photoshop). Does anyone know of an update from Microsoft or an addon to include UML 2.0 (complete - not just class diagrams) in Visio 2003?
I found this package: http://www.sdl.sandrila.co.uk/ but judging by their "example" screenshots, I'm going to stay away. If they don't know how to use UML, I'd be surprised if they could implement it correctly ;)
This set of Visio stencils and templates for UML 2.0 is excellent:
http://softwarestencils.com/uml/index.html
In case it wasn't clear, Microsoft will never update Visio support of UML. For some time, they have not considered Visio to be a Software Engineering tool.
I don't blame them. It didn't even do a good job with the parts of UML it "supported".
I'm using the UML 2.0 symbols from Pavel Hruby. Maybe you'll find them useful as well.
The nice thing about Visio is that it is just a drawing program and not a modeling environment. So just make up your own lines. Visio can draw just about any line time you can think of. But the real answer is the one already checked. Now that Microsoft "supports" UML maybe they will provide better tooling.
Those screenshots are only example diagrams, Sandrila SDL doesn't enforce that level of rigour to the diagrams.
I found this package: http://www.sdl.sandrila.co.uk/ but judging by their "example" screenshots, I'm going to stay away. If they don't know how to use UML, I'd be surprised if they could implement it correctly ;)
That seems a bit harsh - of the handful of screen-shots which are UML2 (as opposed to being examples of the other notations the tool supports, such as SDL, MCL and TTCN), which do you think are incorrect? It's quite ugly as diagrams go, and uses aliased fonts and lines, but that's a Visio feature rather than anything to do with the template.
In terms of what you can do with the UML, you are much better off using a real UML2 tool than Visio. Enterprise Architect is a cheap one which does have a real UML model behind it. (It would be nice to be able to say that the more expensive ones have fewer UI bugs and gotchas, but that isn't really the case, and most lag far behind the simpler graphical tools like OmniGraffle or Visio in polish and usability)