Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm going to start learning and using UML.
I need to know what considerations do you suggest for me? What is the best way to learn effectively it do you think?
Thank you
In a class named SE101- Software Engineering 1A at CPIT in New Zealand.
In my opinion, you'll find that sequence and use case diagrams will be essential for getting ideas across to non-programmers, and class diagrams (and object diagrams, to a lesser extent), for communicating ideas to other code-monkeys.
Plus, many programming books that you may read in the future, Design Patterns, for example, will use UML diagrams (class and object, mostly) to show the structure of the patterns. Knowing UML will make understanding these books a lot easier. Documentation, too, to a lesser extent.
I never did, and I never will. Modelling is not about mastering a type of discipline, good models don't need UML to be understood.
First, get a book/tutorial and try to understand the basics (definitions, models drawing, ...)
then, learn by example and practice, imagine or use a real problem and try to model it.
I started by reading an introductory book - Martin Fowler UML Distilled was quite good. Than I decided I really want to know how to use it, so I read a book about UML2 and UP (Unified Process) by Jim Arlow and Ila Neustadt. Afterward I had opportunity to take software engineering basics lecture at university which made me create simple specification with few diagrams. Afterward I took UML lecture, where I had again to create some UML diagrams. Now I am in the phase when UML is clear and I feel I need more knowledge about OO modeling, so I read a book on object oriented data modeling and object oriented programming and there are Use Cases by Alistair Cockbourne and some analytical patterns ahead for me. In between I read much of the model driven stuff and listened to SE Radio about all UML stuff - http://www.se-radio.net/tags/uml .
UML Distilled by Martin Fowler together with Applying UML And Patterns by Craig Larman, makes you understand the concept of UML and how to use it - as well the whole process with UP and so forth.
http://www.smartdraw.com/resources/tutorials/uml-diagrams/#/resources/tutorials/Getting-Started
This link was very helpful for me to learn modeling with UML.
For open source solutions check out Dia, and dia2code.
I read Martin Fowler's UML Distilled. That's all you need. It's thin, dense book that's unmatched on that topic.
I have several UML books, UML Distilled book from Addison Wesley comes to mind,
then it all gets familiar when you start reading Design Pattern books that illustrates the concepts using UML Diagrams.
I also use UML when I sketch a design.
You can only focus on 2 diagrams and start modeling almost immediately.
Usecase diagrams require reading but class diagram can be done at the same time as the code. It means that in less than 3 hours you can model.
Usecase diagram is simple and will help you to define the scope of your project.
Class diagram will define the physical architecture and can therefore be learned at the same time as codding if you use a tool having live code and model synchronization.
Don't spend time on model driven and code generation from a model because nobody really use it today !!
Inventor.
Sequence diagrams look more like business processes and usecases rather unstandardized.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What diagramming technique(s) do you use while programming to help you
or others understand your program or design. I am not talking about a person's
favorite tool, though a good tool probable helps a person greatly with
diagramming.
My intent in this question is to find the simple useful diagramming techniques
people actually use and find new ones to learn.
Do you use flow-charts, Data Flow Diagrams, ER diagrams, etc?
The web is full of recommendations! But what do real programmers, designers,
and code maintainers actually use in their day to day work.
Thanks for your feedback
Very High Level Discussion - Context Diagrams where the boxes might represent classes, packages, or sub-systems.
High Level Design - Sequence diagrams which show the interface between sub-systems, still no classes directly used but may be implied from this.
Detailed Design - Sequence diagrams which are at the class level.
If there is a tricky algorithm for something such as the correlation of multiple data streams into a new stream then I will generally use a Flow Chart to work out the algorithm.
If the solution requires knowledge of state then a State diagram is also used.
Those are the ones I use most.
When doing Data Warehouse design I draw Star Schemas to work out how to store the data. When doing Transactional DB design I use Entity Relationship diagrams to work our data storage.
When designing a UI I just sketch it out. Once I start to get some parts of the UI worked out and want to play with some areas I will make a template, print out a copy copies and then use that as a guide to work on sub-sections. For colour schemes, it can be handy to make a graphic using the gimp and have layers for each piece of the design and then play with the layers colouring each one to find the right balance.
What do we really use? Maybe other people actually create formal diagrams, but for the most part I just scribble bubbles, boxes and lines on a sheet of paper.
I use a whiteboard for modeling, so I guess "whiteboard modeling language" would be my answer.
I will do a UML Class diagram for anything i'm designing that is bigger than a couple of classes. Drawing a class diagram makes me take time out to think over the design instead of ploughing straight into the code and always produces a better result.
For bigger and more complicated architectures I find that Sequence diagrams are a good way to communicate behviour, especially for multi-threaded systems.
I use diagrams as a way to quickly understand legacy code. It takes some work to create the diagram, but it always pays of in the end.
Normally I use class diagrams to get the big picture. Sometimes sequence diagrams and even dataflow diagram if a piece o code is extremely hard to understand.
In the design phase I use class diagrams, and often state diagrams. State diagrams are perfect if a class behaviour differs with its state.
I use Sequence Diagrams a lot (drawn on paper). I find they give me a nice visual representation the logical flow of method calls and information between various systems and components in our applications.
I have a Flow chart of the main product I work with and develop.
My team also often uses UML diagram sketches on white-boards while designing new parts for us to implement. They're very useful in creating design patterns and modeling the high-level structure of the classes which will be needed. These are never full blown UML though...
Whiteboard for discussions.
Pen and paper for less temporary record.
Code stubs for 'Things to impelement'.
Tested and Working code (with extensive comments) for posterity.
I use ER and class diagrams on paper and whiteboard for any project that's bigger than a shell script.
Flow charts, only when I need to explain a process to a non-programmer (or if it's a really complicated process and I need to understand it first).
My old boss used to say "the guy just loves drawing stuff."
I work in an AJAX development environment, and most of the backend code I write works like a pipe between a relational database and the frontend javascript (user interface). So, the most used 'diagram' per say that I use are JSON objects to describe how data should be passed back and forth between the database and the interface. They are simple, universal and easy to understand data structures.
Example:
{
"id": row['id'],
"name": row['name'],
"mandatory": row['mandatory'],
"rangeDescription": "This is the Range",
"globalRate": row['global']
}
I draw bastardized versions of UML class, object and sequence diagrams. While I try to be true to the syntax, I am much more concerned about expressing the main idea behind particular feature. So, I'll draw up something, ask a colleague to take a look, and if it seems clear enough, we might even scan it and post it in our Wiki.
Then, when it so happens that we actually get some time to work on the documentation (and that is almost never), I'll use BOUML and redraw the scribbles into a proper diagram.
Now, to put is all in context, I'm working at a relatively small team (5 developers), making trading and product configuration platforms in Java. We have our two products that we then additionally customize to customer's requests. Being a close-knit community, with low (zero) turnaround for a few years, we use the documentation primarily as a remainder to ourselves. And in this setup, the above approach works quite well.
I like Data Flow Diagrams. A lot.
I use whatever is needed for communicatation. Usually that's nothing at all. Sometimes it's a whiteboard.
From time to time, I use Sparx Enterprise Architect, which is a UML modeling tool, though it produces decent diagams while it's at it. I've used it for requirements, use case, activity, sequence, domain, and even class modeling, and sometimes some reverse-engineered ER diagrams. Whatever it takes to get the point across.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Okay, so far, I have been taking computer science courses in my high school and doing some of my own research on the web, and I have found I really like the subject. However, the computer science courses, having given me a small amount of experience in a few languages (C++, java, and python), leave me wondering where to go for development on my own.
I would like to create desktop applications, or even web applications if I could wrap my head around it. What language would you think would best facilitate this?
As a side-note, what are some good books or online documents that explain general computer science topics? I have found some good ones, but they haven't given me the depth I really want.What are some good ones?
Find an "itch"--a program you wish existed, that would be useful for you to have, but you can't find (or costs money). Then try writing it, using online resources (like Stack Overflow) to help you.
At this stage in your career, language doesn't matter very much. Some languages are better than others at certain tasks, but often your own level of comfort with the language outweighs other issues. So just pick a language you're interested in, and a project you're interested in, and get to work.
You may find that you need to start with a simpler project, or you may find more resources for a different language or framework. But getting started with something--no matter what that something is--is probably the most important thing.
Here is a classic but still quite relevant book if you ever want to level up from coder to software engineer.
Since you're still in high school, I would tell you that time is on your side. You have plenty of time to develop as a computer scientist. Therefore, take the long view for your development. So it's much better for you to understand the abstractions that underly software technology.
In my humble opinion, C++ and Java will always be around and you have plenty of time to develop your skills in that arena. However, a higher level language like Scheme or Python will pay plenty of dividends. You might find this recommendation highly enlightening.
In addition, every application will deal with a database as its system of record. Understanding SQL and data modeling is a win-win.
Also, understanding formal logic and/or discrete mathematics is indispensable for computer science. Computer languages are nothing but formal languages for executing
procedures: i.e. mathematical induction is used to define their syntax and semantics.
It sounds like you would enjoy jumping into a high level, modern language that's native to the operating system you want to target; Objective-C or C# for example. On the other hand if you really want to do something for the web, building a web app isn't much harder (there are just more choices to pick from for the back end and front end technologies you decide to use).
Basically, decide what project you want to work on and choose the best language for it. What really matters is that you're working on something.
What language to further develop in?
Given that you know C++, Java, and Python already, a next language I might suggest would be SQL and DDL: defining databases, and getting data in and out of them.
If your CS course didn't touch on it, I highly advise spending a bit of time with a more functional style of language like erlang, haskell or even lisp.
They won't become your day-to-day hacking language overnight, but can really help you grasp important programming concepts relavent accross all languages.
....especially the one about choosing the right language for the task at hand.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Question
So I've recently came up with some new possible projects that would have to deal with deriving 'meaning' from text submitted and generated by users.
Natural language processing is the field that deals with these kinds of issues, and after some initial research I found the OpenNLP Hub and university collaborations like the attempto project. And stackoverflow has this.
If anyone could link me to some good resources, from reseach papers and introductionary texts to apis, I'd be happier than a 6 year-old kid opening his christmas presents!
Update
Through one of your recommendations I've found opencyc ('the world's largest and most complete general knowledge base and commonsense reasoning engine'). Even more amazing still, there's a project that is a distilled version of opencyc called UMBEL. It features semantic data in rdf/owl/skos n3 syntax.
I've also stumbled upon antlr, a parser generator for 'constructing recognizers, interpreters, compilers, and translators from grammatical descriptions'.
And there's a question on here by me, that lists tons of free and open data.
Thanks stackoverflow community!
Tough call, NLP is a much wider field than most people think it is. Basically, language can be split up into several categories, which will require you to learn totally different things.
Before I start, let me tell you that I doubt you'll have any notable success (as a professional, at least) without having a degree in some (closely related) field. There is a lot of theory involved, most of it is dry stuff and hard to learn. You'll need a lot of endurance and most of all: time.
If you're interested in the meaning of text, well, that's the Next Big Thing. Semantic search engines are predicted as initiating Web 3.0, but we're far from 'there' yet. Extracting logic from a text is dependant on several steps:
Tokenization, Chunking
Disambiguation on a lexical level (Time flies like an arrow, but fruit flies like a banana.)
Syntactic Parsing
Morphological analysis (tense, aspect, case, number, whatnot)
A small list, off the top of my head. There's more :-), and many more details to each point. For example, when I say "parsing", what is this? There are many different parsing algorithms, and there are just as many parsing formalisms. Among the most powerful are Tree-adjoining grammar and Head-driven phrase structure grammar. But both of them are hardly used in the field (for now). Usually, you'll be dealing with some half-baked generative approach, and will have to conduct morphological analysis yourself.
Going from there to semantics is a big step. A Syntax/Semantics interface is dependant both, on the syntactic and semantic framework employed, and there is no single working solution yet. On the semantic side, there's classic generative semantics, then there is Discourse Representation Theory, dynamic semantics, and many more. Even the logical formalism everything is based on is still not well-defined. Some say one should use first-order logic, but that hardly seems sufficient; then there is intensional logic, as used by Montague, but that seems overly complex, and computationally unfeasible. There also is dynamic logic (Groenendijk and Stokhof have pioneered this stuff. Great stuff!) and very recently, this summer actually, Jeroen Groenendijk presented a new formalism, Inquisitive Semantics, also very interesting.
If you want to get started on a very simple level, read Blackburn and Bos (2005), it's great stuff, and the de-facto introduction to Computational Semantics! I recently extended their system to cover the partition-theory of questions (question answering is a beast!), as proposed by Groenendijk and Stokhof (1982), but unfortunately, the theory has a complexity of O(n²) over the domain of individuals. While doing so, I found B&B's implementation to be a bit, erhm… hackish, at places. Still, it is going to really, really help you dive into computational semantics, and it is still a very impressive showcase of what can be done. Also, they deserve extra cool-points for implementing a grammar that is settled in Pulp Fiction (the movie).
And while I'm at it, pick up Prolog. A lot of research in computational semantics is based on Prolog. Learn Prolog Now! is a good intro. I can also recommend "The Art of Prolog" and Covington's "Prolog Programming in Depth" and "Natural Language Processing for Prolog Programmers", the former of which is available for free online.
Chomsky is totally the wrong source to look to for NLP (and he'd say as much himself, emphatically)--see: "Statistical Methods and Linguistics" by Abney.
Jurafsky and Martin, mentioned above, is a standard reference, but I myself prefer Manning and Schütze. If you're serious about NLP you'll probably want to read both. There are videos of one of Manning's courses available online.
If you get through Prolog until the DCG chapter in Learn Prolog Now! mentioned by Mr. Dimitrov above, you'll have a good beginning at getting some semantics into your system, since Prolog gives you a very simple way of maintaining a database of knowledge and belief, which can be updated through question-answering.
As regards the literature, I have one major recommendation for you: run out and buy Speech and Language Processing by Jurafsky & Martin. It is pretty much the book on NLP (the first chapter is available online); used in a frillion university courses but also very readable for the non-linguist and practically oriented, while at the same time going fairly deep into the linguistics problems. I really cannot recommend it enough. Chapters 17, 18 and 21 seem to be what you're looking for (14, 15 and 18 in the first edition); they show you simple lambda notation which translates pretty well to Prolog DCG's with features.
Oh, btw, on getting the masters in linguistics; if NL semantics is what you're into, I'd rather recommend taking all the AI-related courses you can find (although any courses on "plain" linguistic semantics, logic, logical semantics, DRT, LFG/HPSG/CCG, NL parsing, formal linguistic theory, etc. wouldn't hurt...)
Reading Chomsky's original literature is not really useful; as far as I know there are no current implementations that directly correspond to his theories, all the useful stuff of his is pretty much subsumed by other theories (and anyone who stays near linguists for any matter of time will absorb knowledge of Chomsky by osmosis).
I'd highly recommend playing around with the NLTK and reading the NLTK Book. The NLTK is very powerful and easy to get into.
You could try reading up a bit on phrase structured grammers, which is basically the mathematics behind much language processessing. It's actually not that heavy, being largely based on set and graph theory. I studied it many moons ago as part of a discrete math course, and I guess there are many good references available at this stage.
Edit:Not as much as I expected on google, although this one looks like a good learning source.
One of the early explorers into NLP is Noam Chomsky; he wrote small books on the subject in the 50s through the 70s. You may find that engaging reading.
Cycorp have a short description of how their Cyc knowledge base derives meaning from sentences.
By utilising a massive knowledge base of common facts, the system can determine the most logical parse of a sentence.
A simpler place to begin with the building blocks is the look at the documentation for a package that attempts to do it. I'd recommend the Python [Natural Language Toolkit (NLTK)1, particularly because of their well-written, free book, which is filled with examples. It won't get you all the way to what you want (which is an AI-hard problem), but it will give you a good footing. NLTK has parsers, chunkers, context-free grammars, and more.
This is really hard stuff. I'd start off by getting at least a Masters in Linguistics, and then work towards my PhD in computer science, concentrating on NLP.
The problem is that most of us don't have the understanding of what language is. And without that understanding, it's bloody tough to implement a solution.
Other comments give some readings, which are probably fine if you want to get started playing around with a small subset of the problem, but in order to come up with a really robust solution, then there are no shortcuts. You need the academic background in both disciplines.
A very enjoyable readable introduction is The Language Instinct by Steven Pinker. It goes into the Chomsky stuff and also tells interesting stories from the evolutionary biology angle. Might be worth starting with something like that before diving into Chomsky's papers and related work, if you're new to the subject.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
In college I've had numerous design and UML oriented courses, and I recognize that UML can be used to benefit a software project, especially use-case mapping, but is it really practical? I've done a few co-op work terms, and it appears that UML is not used heavily in the industry. Is it worth the time during a project to create UML diagrams? Also, I find that class diagrams are generally not useful, because it's just faster to look at the header file for a class. Specifically which diagrams are the most useful?
Edit: My experience is limited to small, under 10 developer projects.
Edit: Many good answers, and though not the most verbose, I belive the one selected is the most balanced.
Using UML is like looking at your feet as you walk. It's making conscious and explicit something that you can usually do unconsciously. Beginners need to think carefully about what they're doing, but a professional programmer already knows what they're doing. Most of the time, writing the code itself is quicker and more effective than writing about the code, because their programming intuition is tuned to the task.
It's not just about what you're doing though. What about the new hire who comes in six months from now and needs to come up to speed on the code? What about five years from now when everyone currently working on the project is gone?
It's incredibly helpful to have some basic up to date documentation available for anyone who joins the project later. I don't advocate full blown UML diagrams with method names and parameters (WAY too difficult to maintain), but I do think that a basic diagram of the components in the system with their relationships and basic behavior is invaluable. Unless the design of the system changes drastically, this information shouldn't change a lot even as the implementation is tweaked.
I've found that the key to documentation is moderation. No one is going to read 50 pages of full blown UML diagrams with design documentation without falling asleep a few pages in. On the other hand, most people would love to get 5-10 pages of simple class diagrams with some basic descriptions of how the system is put together.
The other case where I've found UML to be useful is for when a senior developer is responsible for designing a component but then hands the design to a junior developer to implement.
In a sufficiently complex system there are some places where some UML is considered useful.
The useful diagrams for a system, vary by applicability.
But the most widely used ones are:
Class Diagrams
State Diagrams
Activity Diagrams
Sequence Diagrams
There are many enterprises who swear by them and many who outright reject them as an utter waste of time and effort.
It's best not to go overboard and think what's best for the project you are on and pick the stuff that is applicable and makes sense.
Using UML is like looking at your feet as you walk. It's making conscious and explicit something that you can usually do unconsciously. Beginners need to think carefully about what they're doing, but a professional programmer already knows what they're doing. Most of the time, writing the code itself is quicker and more effective than writing about the code, because their programming intuition is tuned to the task.
The exception is why you find yourself in the woods at night without a torch and it's started to rain - then you need to look at your feet to avoid falling down. There are times when the task you've taken on is more complicated than your intuition can handle, and you need to slow down and state the structure of your program explicitly. Then UML is one of many tools you can use. Others include pseudocode, high-level architecture diagrams and strange metaphors.
Generic work-flow and DFDs can be very useful for complex processes. All other diagramming (ESPECIALLY UML) has, in my experience, without exception been a painful waste of time and effort.
I'd have to disagree, UML is used all over the place - anywhere a IT project is being designed UML will usually be there.
Now whether it is being used well is another matter.
As Stu said, I find both Use Cases (along with the use case descriptions) and activity diagrams to be the most helpful from a developer point of view.
Class diagram can be very useful when trying to show relationships, as well as object attributes, such as persistence. When it comes to adding ever single attribute or property they are usually overkill, especially as they often become out of date quickly once code is written.
One of the biggest problems with UML is the amount of work required to keep it up to date once code is being generated, as there are few tools that can re-engineer UML from code, and few still that do it well.
I will qualify my answer by mentioning that I don't have experience in large (IBM-like) corporate development environments.
The way I view UML and the Rational Unified Process is that it's more TALKING about what you're going to do than actually DOING what you're going to do.
(In other words it's largely a waste of time)
Throw away only in my opinion. UML is a great tool for communicating ideas, the only issue is when you store and maintain it because you are essentially creating two copies of the same information and this is where it usually blows.
After the initial round of implementation most of the UML should be generated from the source code else it will go out of date very quickly or require a lot of time (with manual errors) to keep up to date.
I co-taught a senior-level development project course my last two semesters in school. The project was intended to be used in a production environment with local non-profits as paying clients. We had to be certain that code did what we expected it to and that the students were capturing all the data necessary to meet the clients' needs.
Class time was limited, as was my time outside of the classroom. As such, we had to perform code reviews at every class meeting, but with 25 students enrolled individual review time was very short. The tool we found most valuable in these review sessions were ERD's, class diagrams and sequence diagrams. ERD's and class diagrams were done only in Visual Studio, so the time required to create them was trivial for the students.
The diagrams communicated a great deal of information very quickly. By having a quick overview of the students' designs, we could quickly isolate problem areas in their code and perform a more detailed review on the spot.
Without using diagrams, we would have had to take the time to go one by one through the students' code files looking for problems.
I am coming to this topic a little late and will just try an clarify a couple minor points. Asking if UML is useful as far too broad. Most people seemed to answer the question from the typical/popular UML as a drawing/communication tool perspective. Note: Martin Fowler and other UML book authors feel UML is best used for communication only. However, there are many other uses for UML. Above all, UML is a modeling language that has notation and diagrams mapped to the logical concepts. Here are some uses for UML:
Communication
Standardized Design/Solution documentation
DSL (Domain Specific Language) Definition
Model Definition (UML Profiles)
Pattern/Asset Usage
Code Generation
Model to Model transformations
Given the uses list above the posting by Pascal is not sufficient as it only speaks to diagram creation. A project could benefit from UML if any of the above are critical success factors or are problem areas that need a standardized solution.
The discussion should expanded out from how UML can be over kill or applied to small projects to discuss when UML makes sense or will actually improve the product/solution as that is when UML should be used. There are situations where UML for one developer could sense as well, such as Pattern Application or Code Generation.
UML has worked for me for years. When I started out I read Fowler's UML Distilled where he says "do enough modelling/architecture/etc.". Just use what you need!
From a QA Engineer's perspective, UML diagrams point out potential flaws in logic and thought. Makes my job easier :)
Though this discussion has long been inactive, I have a couple of -to my mind important- points to add.
Buggy code is one thing. Left to drift downstream, design mistakes can get very bloated and ugly indeed. UML, however, is self-validating. By that I mean that in allowing you to explore your models in multiple, mathematically closed and mutually-checking dimensions, it engenders robust design.
UML has another important aspect: it "talks" directly to our strongest capability, that of visualisation. Had, for example, ITIL V3 (at heart simple enough) been communicated in the form of UML diagrams, it could have been published on a few dozen A3 foldouts. Instead, it came out in several tomes of truly biblical proportions, spawning an entire industry, breathtaking costs and widespread catatonic shock.
I believe there may be a way to utilize Cockburn style UML fish,kite, and sea-level use cases as described by Fowler in his book "UML Distilled." My idea was to employ Cockburn use cases as an aid for code readability.
So I did an experiment and there is a post here about it with the Tag "UML" or "FOWLER." It was a simple idea for c#. Find a way to embed Cockburn use cases into the namespaces of programming constructs (such as the class and inner class namespaces or by making use of the namespaces for enumerations). I believe this could be a viable and simple technique but still have questions and need others to check it out. It could be good for simple programs that need a kind of pseudo-Domain Specific Language which can exist right in the midst of the c# code without any language extensions.
Please check out the post if you are interested. Go here.
I think the UML is useful thought I think the 2.0 spec has made what was once a clear specification somewhat bloated and cumbersome. I do agree with the edition of timing diagrams etc since they filled a void...
Learning to use the UML effectively takes a bit of practice. The most important point is to communicate clearly, model when needed and model as a team. Whiteboards are the best tool that I've found. I have not seen any "digital whiteboard software" that has managed to capture the utility of an actual whiteboard.
That being said I do like the following UML tools:
Violet - If it were any more simple it would be a piece of paper
Altova UModel - Good tool for Java and C# Modeling
MagicDraw - My favorite commercial tool for Modeling
Poseidon - Decent tool with good bang for the buck
StarUML - Best open source modeling tool
UML diagrams are useful for capturing and communicating requirements and ensuring that the system meets those requirements. They can be used iteratively and during various stages of planning, design, development, and testing.
From the topic: Using Models within the Development Process at http://msdn.microsoft.com/en-us/library/dd409423%28VS.100%29.aspx
A model can help you visualize the world in which your system works, clarify users' needs, define the
architecture of your system, analyze the code, and ensure that your code meets the requirements.
You might also want to read my response to the following post:
How to learn “good software design/architecture”? at https://stackoverflow.com/questions/268231/how-to-learn-good-software-design-architecture/2293489#2293489
I see sequence diagrams and activity diagrams used fairly often. I do a lot of work with "real-time" and embedded systems that interact with other systems, and sequence diagrams are very helpful in visualizing all the interactions.
I like to do use-case diagrams, but I haven't met too many people who think they are valuable.
I've often wondered whether Rational Rose is a good example of the kinds of applications you get from UML-model-based design. It's bloated, buggy, slow, ugly, ...
I found UML not really useful for very small projects, but really suitable for larger ones.
Essentially, it does not really matter what you use, you just have to keep two things in mind:
You want some sort of architecture planning
You want to be sure that everyone in the team is actually using the same technology for project planning
So UML is just that: A standard on how you plan your projects. If you hire new people, there are more likely to know any existing standard - be it UML, Flowchard, Nassi-Schneiderman, whatever - rather than your exising in-house stuff.
Using UML for a single developer and/or a simple software project seems overkill to me, but when working in a larger team, I would definitely want some standard for planning software.
UML is useful, yes indeed! The main uses I've made of it were:
Brainstorming about the ways a piece of software should work. It makes easy to communicate what you are thinking.
Documenting the architecture of a system, it's patterns and the main relationships of its classes. It helps when someone enters your team, when you're leaving and want to make sure your successor will understand it, and when you eventually forget what the hell that little class was meant for.
Documenting any architectural pattern you use on all your systems, for the same reasons of the dot above
I only disagree with Michael when he says that using UML for a single developer and/or a simple software project seems overkill to him. I've used it on my small personal projects, and having them documented using UML saved me a lot of time when I came back to them seven months later and had completely forgotten how I had built and put together all those classes.
One of the problems I have with UML is the understandability of the specification. When I try to really understand the semantics of a particular diagram I quickly get lost in the maze of meta-models and meta-meta-models. One of the selling points of UML is that it is less ambiguous than natural language. However, if two, or more, engineers interpret a diagram differently, it fails at the goal.
Also, I've tried asking specific questions about the super-structure document on several UML forums, and to members of the OMG itself, with little or no results. I don't think the UML community is mature enough yet to support itself.
Coming from a student, I find that UML has very little use. I find it ironic that PROGAMERS have yet to develop a program that will automatically generate the things that you have said are necessary. It would be extremely simple to design a feature into Visual Studio that could pull pieces of the data, seek for definitions, and product answers sufficent so that anyone could look at it, great or small, and understand the program. This would also keep it up to date because it would take the information directly from the code to produce the information.
UML is used as soon as you represent a class with its fields and methods though it's just a kind of UML diagram.
The problem with UML is that the founders book is too vague.
UML is just a language, it's not really a method.
As for me, I really find annoying the lack of UML schema for Opensource Projects. Take something like Wordpress, you just have a database schema, nothing else. You have to wander around the codex api to try to get the big picture.
UML has its place. It becomes increasingly important as the size of the project grows. If you have a long running project, then it is best to document everything in UML.
UML seems to good for large projects with large teams of people. However I've worked in small teams where communication is better.
Using UML-esque diagrams is good though, especially in the planning stage. I tend to think in code, so I find writing large specs hard. I prefer to write down the inputs' and outputs' and leave the developers to design the bit in the middle.
I believe UML is useful just for the fact that it gets people to think about the relationships between their classes. It is a good starting point to start thinking about such relationships, but it is definitely not a solution for everybody.
My belief is that the use of UML is subjective to the situation in which the development team is working.
In my experience:
The ability to create and communicate meaningful code diagrams is a necessary skill for any software engineer who is developing new code, or attempting to understand existing code.
Knowing the specifics of UML - when to use a dashed line, or a circle endpoint - is not quite as necessary, but is still good to have.
UML is useful in two ways:
Technical side: a lot of people (manager and some functional analyst) think that UML is a luxury feature because The code is the documentation: you start coding, after you debug and fix. The sync of UML diagrams with code and analisys force you to understand well the requests of the customer;
Management side: the UMl diagrams are a mirror of the requires of the customer who is inaccurate: if you code without UML, maybe you can find a bug in requires after a lot of hours of work. The diagrams UML allow you to find the possible controversal points and to resolve before the coding =>help your planning.
Generally, all the projects without UML diagrams have a superficial analysis or they have short size.
if you're in linkedin group SYSTEMS ENGINEERS, see my old discussion.
UML is definitely helpful just as junit is essential. It all depends how you sell the idea. Your program will work without UML just as it would work without unit tests. Having said that, you should create do UML as along it is connected to your code, i.e when you update UML diagrams it updates your code, or when you update your code it auto generates the UML. Don't do just for the sake of doing it.
UML definetly has its place in the industry. Imagine you are building software for Boing aircraft or some other complex system. UML and RUP would be great help here.
In the end UML only exist because of RUP. Do we need UML or any of its related stuff to use Java/.Net ? The practical answer is they have their own documenation (javadoc etc) which is sufficient and lets us get our job done!
UML no thanx.
UML is just one of methods for communication within people.
Whiteboard is better.