I know a lot of places use UML and the unified process as their development model... but then there's a lot that don't. Would it be important to have more than a basic and functional understanding of these subjects or would it be better to focus on developing programming skills in other areas (i.e. language development, IDEs, etc)?
10
-
9+1 really how many developers actually use UML as part of their development process ?– Aditya PMar 15, 2011 at 4:57
-
1It's definitely an industry by industry thing. I'm not sure what realms you're looking in, but I have no doubt that there exist ones where UML is heavily used. Personally in 16 years of professional development I've never even heard a rumour of anyone using it. :-)– Carson63000Mar 15, 2011 at 11:04
-
3Deep enough to know why it often isn't a very good idea to use it.– biziclopMar 15, 2011 at 11:57
-
4@Kenneth Unified process works well if all the requirements are known up front, none of the requirements are going to change significantly, your dev team is fairly big and disciplined and you've got loads of time to perform the steps of the process properly. This rules out the vast majority of dev projects, it certainly rules out every single one I've worked on.– biziclopMar 15, 2011 at 13:52
-
1UML when used by skilled developers saves more time than it costs. When design is done correctly, there is comparitively very little time actually coding and rewriting of that code. Tests can be planned and created long before code even exists and the design tends to actually be an overall system design and not just a bunch of modules attached together by random glue that I've seen on agile projects. The downside with what I've said is the key requirement, "It has to be done by skilled developers". But, there aren't many people who are even capable of those skills let alone have them.– DunkMar 15, 2011 at 15:55
|
Show 5 more comments
7 Answers
Unless you think watching paint dry while neck-deep in sewage is a jolly good time, ignore the Unified Process. Wait, ignoring it is not enough. Fear it. As far as I know, it's only used these days by enormous places that are beyond all hope of efficiency, quality, or sanity.
UML, on the other hand, can be a handy notation for important programming concepts. Get Martin Fowler's UML Distilled, give it a skim, and practice sketching diagrams while thinking about design. It's a skill I use regularly and I'm glad I have it.
Be aware that people try to over-use UML. Whiteboard UML while discussing things is awesome. An occasional diagram in published documentation can be nice. But the quest to document your entire code base in UML is pointless and wasteful. And the desire to "program in UML" is idiotic. If you come across people like that, flee. But first, brand their foreheads with a sequence diagram, so the rest of us are properly warned.
answered Mar 16, 2011 at 0:00
-
I'm ROTFLOL!!! hahaha... its so funny that you should mention the people who consider the possibility of programming in UML... a few of my class mates started getting into that discussion and I thought they were going a little out there! hahaha– KennethMar 16, 2011 at 0:40
-
2Thanks, Kenneth. People have been talking about programming in diagrams since you could draw diagrams on the computer. It never works for serious code, but people who haven't thought it through keep trying. Mar 16, 2011 at 1:01
Don't spend too much time on UML. In my team I am the only one to know really well UML and therefore create use case, component, state, deployment and other diagrams. The other team members are better than me for codding but not as good for the UML diagramming.
The trick we use is to focus on the class diagram at modeling level to define the structure of the application and also let the developper/architect to code as they want. We then merge the model with the new code and update the model at each iteration. Really easy and very efficient. We develop in Java with Omondo EclipseUML.
I would recommend not to use any MDD which is for me a real crap !! Modeler will try to take more power inside development process but this will not create any value if they try to generate all the code from the model. The code belongs to the developer/architect but not to the modeler. UML should only be a view of the project requirements (e.g. usecase, sequence, etc....) the process (e.g. state or activty diagram), deployment (deployment, component diagrams). The class diagram should a view of the code and UML class diagram should only be used as a viewer of the code. Java coding should respect object approach and UML which is also an object language is really helpful to avoid crap and stupid codding.
The most important is the class diagram iterations between model to code and code to model. I don't really mean live synchronization, but to be able to merge code and model at each iteration. I use Omondo EclipseUML and think they are the only one to have merge java, database entities and model IDs. The ID merge is really a powerful concept and is perfect for our agile projects.
My recommendation is not to buy any book. You should have an object approach and use class diagram language to visualize your objects in order to create better architectures. If one of the team member knows UML then use the other diagrams, if not the class diagram would be sufficient.
The Unified Process and UML are a set of structured thinking and communication tools. These tools help in a few ways; both by defining a way of talking about designs, and by helping us work through the details and facets of our designs.
Improving your own thinking is critical for completing the details of a design and for finding your path to a sane and coherent product. Personal disciplines help you focus, keep track of details, think through the edges, and remember what your thinking is months later.
Improving how the design is talked about and improved is critical for getting a group of designers get further, faster. Group disciplines help get more from the group.
But remember tat UML and the Unified Process are only one of many thinking tools. They're reasonable, but they may or may not fit you or your group (which is as important as any other factor).
-
1Would it be safe to say that for the most part as long as I'm able to work in a structured way like or similar to the unified process that I'll be able to learn whatever process is in use on the job and should therefore develop my programming skills instead?– KennethMar 15, 2011 at 6:08
-
-
No, I think it's worth learning a few structured methods and then picking what works for you. You may end up with your own process, but there's much to learn from those who came before you. I personally use pieces of a number of processes: agile, unified, and even a few older pieces (like RFC-style specs, timing graphs, etc.). Mar 16, 2011 at 0:16
In my mind there is now way around UML. Get a book and learn it. You need it to :
- read technical books that use UML (there are a lot)
- use it as a sketching tool to discuss idea's/solutions with colleges.
- give yourself a quick way to visualize the solution you are thinking of and reason about it.
- read/reason about technical/functional designs at certain companies
The unified process I think is a different story, it depends on the employer you are at. I would read a book at least to know what it is and when the time comes that you really need it study it.
Hope this helps.
I don't think that you need an extremely in-depth knowledge of UML but you should definitely be able to look at a diagram and be able to tell what's going on. What you SHOULD try to get an in-depth knowledge is different design patterns (buy a book). When you come up with your own designs, it will help you to know both the design pattern and UML pattern even if you don't actually draw it out. It also helps you in understanding a UML diagram when you see it, because you might understand a little better why the UML looks like that.
answered Mar 15, 2011 at 11:55
-
-
I read java design patterns by james cooper from 2000 because my library had it. I got what I needed out of it but I think that it could have been written much better. "Which books/websites would you recommend for learning design patterns?" sounds like a great question for this website (personally I prefer books). Mar 16, 2011 at 1:16
-
I've been in this biz since 1987 and the only times I've dealt with UML and the Unified Process was a few occasions when some misbegotten consultant got paid some very big bucks to force feed the staff with all the minutiae of these overhyped, overblown, and tendentious methodologies. In the aftermath of every attempt to apply this unadulterated crap we ended up generating enough almost-immediately obsolete documentation to fill the Library of Congress to overflowing and beyond, while simultaneously slowing the design and development of our projects unconscionably.
If your business product is to be measured in pounds of paper and/or the size of the documentation, will never be read more than once (if that many), and will forever afterwards be obsolete, and that will be the basis on which you are paid, then by all means, go whole hog with this crap.
If otherwise, run screaming for the hills upon the first mention of UML and UP. Or better, beat the first person who utters it to a pulp.
answered Mar 16, 2011 at 0:26
You may mention that you could use U.M.L. WITHOUT the Unified Process. I use a lot of U.M.L. at the same time than programming, but, for me is important to be in a practical way, not just use it because "its a shinny new tool".
Class diagrams, use cases and sequential diagrams are my favorite. I don't require use other kinds of diagrams as often, as these ones.
Many companies doesn't use the Unified/Rational Process.
