On Sat, Mar 31, 2012 at 2:34 PM, Mark Fortner <[email protected]> wrote:
> Does the process above roughly fit the way everyone else is using ArgoUML at > work? Has anyone had any problems getting other people to use ArgoUML at > work? If so, what get's in the way? How do people use ArgoUML in teams? > Do you do design reviews, if so, how do you use ArgoUML to make that > happen? Do you generate code from ArgoUML models? If not, why not? I'd argue that the developers are the least interesting community to ask this question of. In my mind, many of ArgoUML's shortcomings can be traced to lack of engagement with real world users. Some of the things I use (or have used) ArgoUML for include: - to sketch little design vignettes to share with people (a handful of classes on a single diagram) - to look at UML models created by other people (often standards groups, usually using a different tool, which can create interchange problems) - to visualize and understand new, large code bases using reverse engineering (not very successfully usually due to some of the problems others have mentioned) - as an input tool for MDA using AndroMDA (mainly to get a lot of the db table generation cruft done like Andreas) I would never attempt to keep code and UML in sync using ArgoUML. That's an awful lot of effort for very little gain. I *might* try to do it if I had really excellent round-tripping support available to me, but probably not even then. Thinking of UML as the "design" is a fallacy in my mind. The design is an abstract thing which lives in the shared understanding of the team members. To the degree that the team members haven't converged on a shared design, there are N designs (or perhaps a single design with fuzzy edges). The UML, the design documents, the code, the white board drawings are all *representations* of the design, with varying degrees of fidelity, but they are not *the design*. I don't think the industry has yet to come up with a way to capture designs which is lightweight enough to use on a consistent basis, but also preserves all the important aspects of the design. You either end up investing huge amounts of time/money in design documentation which a) usually isn't used and b) when it is used is *still* missing some important aspect of the design or you end up going the "agile" approach and maintaining the design information using social constructs (supported by code & tests), but leaving yourself at risk for losing key design information when staffing changes. Tom p.s. It's been a while since I played with it, but a local (to me) company that's trying to address some of these challenges is Architexa. http://www.architexa.com/ They've got an online collaboration site for open source projects at http://www.codemaps.org/ which demonstrates some of the collaborative/review aspects. Not a plug for a competitor - just something interesting to look at for people interested in this space. ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2943771 To unsubscribe from this discussion, e-mail: [[email protected]]. To be allowed to post to the list contact the mailing list moderator, email: [[email protected]]
