I studied OOD in my college courses and I'm fairly familiar with UML. How many people are actually using UML in the workplace and to what extent? How accurately do your initial models represent the final objects? Do you use UML in more for design or to document? In your opinion, do you ever sacrifice efficiency in over analysis? Are you certified as an Architect?
I am not a certified architect. We use UML to the extent it is required. Trying to capture everything in UML can be an overkill sometimes. We do round-trip-software development using UML ( Rational Rose ) and so our UML always reflect the "current" classes used by our system. This (indirectly) also serves as a documentation process. By the way, we don't use Java!! ------------------ Ajith Kallambella M. Sun Certified Programmer for the Java�2 Platform. IBM Certified Developer - XML and Related Technologies, V1. [This message has been edited by Ajith Kallambella (edited February 20, 2001).]
Open Group Certified Distinguished IT Architect. Open Group Certified Master IT Architect. Sun Certified Architect (SCEA).
We use UML for design and the end work product serves as documentation for the design. We use a four phase process for doing OOD. Our initial models usually differ dramatically from the final objects due to refining the objects in our different phases. We have no "certified" Architects in house.....
Originally posted by Andrew Shafer: How many people are actually using UML in the workplace and to what extent? How accurately do your initial models represent the final objects? Do you use UML in more for design or to document? In your opinion, do you ever sacrifice efficiency in over analysis? Are you certified as an Architect?
We don't use UML. (Although a different division of my company does.) It depends on how you define initial and final. I'm a big believer in prototypes, or "design it, built it, throw it away, and start all over again." Of course, our documentation should always reflect the current design at the end. In general, I view UML like Robert's Rules of Order. Every try to run a meeting of 6 people using Robert's Rules? It's overkill. How about 600? Then you better have a very formal system, and Robert's Rules are a good starting point. The same holds true for UML, especially given how appliable the 80/20 rule is to it. I was talking to Daniel Jackson (was at CMU now at MIT) who recommends using Alloy, as a lightweight alternative to UML. I haven't had time to look into it yet. http://sdg.lcs.mit.edu/alloy/ I'm not a certified architect. --Mark firstname.lastname@example.org
I don't think UML is helpful only for projects that has many people working on, even though undoubtedly it helps a lot in communication. In fact, it also helps a lot in making sure your design works the way the it's supposed to. I used UML for a few projects and it turns out that by doing some simple use-case diagrams and sequence diagrams, some problems in the client's requirement comes out and we feel lucky that we discover those problems in the very early stage, and be able to discuss with the client before it's too late. We also use class diagram as its always easier to see the design from a graphical presentation, rather than trying to look at a bunch of source code and try to figure out what's going on. In addition to all this, since it's easier to review designs presented in UML, we sometimes even figure out that some portions of the design can actually be replaced by existing patterns.
Where I work, we use UML, RUP religiously. We don�t use everything of course, or we would never get any programming done(we use Java). We break things down into small pieces and then do iterations on those pieces. I know of one person on our team, for which KNOWING UML put him over the edge, and it got him the JOB.
Joined: Dec 04, 2000
Originally posted by rickycli: I don't think UML is helpful only for projects that has many people working on, even though undoubtedly it helps a lot in communication. In fact, it also helps a lot in making sure your design works the way the it's supposed to.
You misunderstand me. To continue with my further anology, in a meeting of 6 people, you still need some type of moderation, just not an overly complex one, such as Robert's Rules. I never said not to use diagrams and related ideas. The benefit of UML is that it is a common language. In small groups, it's easier to get everyone to agree on a common, custom, home-grown notation. At that point, UML may be overkill. In large groups, it's easier to go with a standard. --Mark email@example.com
I'm not a certified Architect (but am SCJP). We use UML here, but not efficiently. We have the tools (Rational Rose) but the team is split on views. Half are the type who just want to code, code, code, and the other half would like a better process for analysis and design. It takes the focus of all team members to implement it effectively. I use it to convey the designs I work on, but I have found that not all of my peers understand it well enough for it to be an effective means of communication. It is frustrating, because the answers are in front of them, but I still have to explain. The really irritating part of this is that I'm the most junior person on the team!!! I use the UML to design, then have a convenient artifact to put into my documentation. This makes the managers happy. Efficiency over analysis? This is a fun topic. Rational Unified Process versus Extreme Programming. A shop has to take the elements IT needs, and come up with a process it likes. There can be a fine line between analysis for the sake of analysis, and not enough analysis to produce a decent product. Oh, also, the high end UML tools (TogetherJ, GDPro, and Rose) support team development. You just need to be in a shop that can shell out $3K per seat. Chris
We use use cases extensively to document requirements. Other than that, we have one person who is designated as system architect. He has Rose and uses only UML design the system. The developers essentially don't use it at all. I've tried to document some of the things I do with UML, but I end up explaining it as well. Currently our initial model is updated through design, but hasn't been kept up through coding. I think sacrificing efficiency for analysis is really hard not to do. Most people want to go ahead and DO something and too often analysis doesn't feel like something. I like to get all the requirements at a high level (breadth first) and then try to get details on a specific area (depth). I think prototyping and iterative development help you do this. No, I'm not a certified architect, and neither is the person doing the architecture here.