Here are some uses for UML:. 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.
UML has worked for me for years. Just use what you need! Makes my job easier :. I think the UML is useful thought I think the 2. 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.
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.
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. 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. Instead, it came out in several tomes of truly biblical proportions, spawning an entire industry, breathtaking costs and widespread catatonic shock. 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'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, 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.
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. 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. 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. 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. 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. On the other hand, I heard from many graduates that UML does not seem to be used in the trenches anymore. They are all used in practice.
But not everyone uses them. Some people eschew design entirely, and leap straight into coding. You cannot rely on anecdotal evidence to know what "everyone" does. Creating them just for the sake of doing them or because the process says you must is not productive. Best practice is to be selective on what you diagram, and what kinds that you use.
Use UML when and where it helps UML was primarily designed as a design tool. It is not so effective these days as a documentation tool. Typical IDEs help you to visualize many aspects if a code base structure on the fly. UML is still used in the trenches. But, as always, people use a subset of it.
Which subset is subject to the problems at hand. UML comes in many versions. But, as always, people use it's symbols informally and inconstantly.
UML is how we understand much of the patterns books out there. It's also one of the ways we communicate on the whiteboard.
It isn't gone. But it's never going to be used as formally as code. It comes in weird local dialects, mixed with other systems, and sometimes we just make up our own symbols. Teach them that it's ok to ask what things mean. But if UML was only ever meant to be a set of symbols with loose semantics, why did he lend his name to its formalisation? Whatever the motives, the evidence is clear.
UML has not had a positive, lasting impact on software delivery. Elaboration as a philosophy did not lead to better software faster and has rightly died. Model driven approaches may still be a niche market. But where they do have traction, the common feature is automation. Producing better software quicker. Booch himself has said that rising abstraction is a fundamental theme in software evolution.
No arguments there. But the implicit consequence is that the translation from progressively higher abstractions to those underneath has to be automated.
Without that, the commercial and cognitive benefits diminish greatly. UML is a graphic exemplar of that pun intended. Your comment reminded me that I had forgotten several recent tweets that in fact were the ones to trigger the writing of this post. Why he accepted or maybe resisted but had to concede defeat to more pragmatic reasons to play along the company is something will probably never know.
Even hardcore programmers agree that any help in understanding the code is useful. Reverse engineering triggered some thought. You reverse engineer some models from code and your change and repeat. Providing some graphical and non graphical abstraction helps work with existing code.
OK, I too will bite. Disclaimer: This is all anecdotal evidence and therefore has no scientific standing.
The software was also easier to test. Since then I have used the Xylogics and Enterprise Architect UML tools on various real-time systems with teams of two or three people up to people scattered across multiple continents. When the modeling tools were used, communicating the system architecture with the other members of the team was much more effective, and maintaining the systems over time was easier.
Modeling makes software engineering easier and less error prone. When models are not used, the process has often degenerated into crude hacking with quality to match. It may be that UML is falling into disuse and modeling is a backwater. But what else do we have? I used the Shlaer-Mellor tools Bridgepoint , even worked for the company.
They — in common with ObjecTime — met the automation need. The Unification process involved many more heads and approaches than those of the 3 Amigos, not to mention numerous CASE tool makers of the time suppliying dis proof-of-concept for numerous candidate notations. The real work from 0. In fact, the opinions currently displayed include those of Bran Selic. We could learn a few interesting things. That horribly failed project back in the day.
Quoted 8 weeks to generate a requirements document and particular experimental prototypes for certain narrow areas to explore those requirements. Allowed two weeks for requirements gathering. The rest was then expected to be cycles of requirements and prototyping. This was all readily spelt out in the contract.
I made the mistake of using UML. They argued about lines and shapes of the sequence diagrams for around 3 days. Then it was fonts. Then it was colors. They wanted images. They wanted all sorts of nonsense in the diagrams. But the actual content? Apparently not so important. Three weeks passed without a single line of code and the requirements gathering still wasn't complete or even approaching a first draft.
I aborted it before this project had a chance to go into actual development which was the next stage and a separate contract. I learnt many valuable lessons. Including the wise counsel of having a contract with exit clauses. Thank you to the lawyer who wrote it up at relatively minor cost. The same lawyer who apparently was a waste of time according to colleagues at the time. Colleagues I later abandoned when they made other stupid decisions.
Always get contracts verified by legal representation. Sounds obvious. But apparently not. UML wasn't actually the issue. I just lacked the crayons and experience to stop what would later come to be termed "bike-shedding". Because the diagrams etc were "human readable" it was deemed that anyone could have an opinion.
So they did. Ad nauseum. Later projects went better when I limited the size of requirements gathering and who could make changes. Experience built up and my BS detector got a lot better. But I kind of didn't mind UML as such. I actually prefer waterfall. Real waterfall is cyclic and resembles agile. But no one ever does it that way. They think it locks things in at each stage and the deliverables are like unchangeable stone tablets from on high.
So painful when done that way. I remember creating these absolutely beast UML diagrams that looked more like spider webs. It was fun, but absolutely useless in the real world lol. My personal view: kill the garbage that is UML with fire, and all the attempts at formal modeling. Design is too rich of a field to be modeled formally. I disagree with the author's apparent take that all there is is either formal UML-type thought systems or a mess of design-less fluffy user stories.
There is room for both. But a thoughtful design represents and communicates deep thought, and formal design systems like UML, in my experience, do not help people communicate deep thoughts. The best design documents that I've read were very well-written prose, with occasional diagrams for illustration, or even code snippets, but not trying to convey too much in a formal manner which would've made the doc less readable not more.
UML was stupid, over-complicated, unproven, horrible to work with, and if that wasn't bad enough, it was mostly people who didn't know how to code very well that advocated for it. It's been dead for a while now. Just being brutally honest. I think all of us who studied CS at least over 10 years ago, no idea what's being taught now hated UML.
That said, there have been plenty of times where I have used certain kinds of UML. For example, sequence diagrams [1] are a great way of modelling certain processes between actors and objects within your system. I even used once a few months ago to help a client understand a complicated part of the system we had developed.
I tend to think more junior CS graduates might end up pulling this kind of thing together using sticky notes in some web 2.
I tried UML years ago with little success. I recently started working with BPMN 2 with some success -- swimlanes are easy to explain and make sense to most people. ERD's are still my favorite notation and really stood the test of time! I think uml is not a efficent way for me to pick up information. I learn them in the university and all, but don't think i actually used them really on my jobs. When I look up a design pattern, I try to understand it from a uml diagram, but almost immediately quickly jump to wikipedia for example code, as i consider it way more digestible.
Not a coincidence, since i deal with code every code, with uml diagrams almost never. For states, I like plain old state diagrams. I only find the the Doxygen generated inheritance hierarchies to be usefull.
I've always thought of OOP as structuring a program the same way you'd structure a business. There are distinct divisions with responsibilities and internal state, with somewhat well defined ways to communicate with each other. Part of why OOP got so popular in software businesses is because it removes an impedance mismatch between the functions of business and the software it produces. In this view, UML is a kind of intermediate bytecode between business planning and software planning.
Parametric diagrams will probably come in handy at some point, as well. SysML users tend to be in less vocal industries, especially those making expensive expensive hardware with lots of up-front design eg. I expect we'll keep using it until something better comes along. Three things happened to UML: 1.
Modeling and analysis became devalued, adversely impacting modeling languages 3. So, with a reduced role for visual modeling languages you've got two competing standards in the area from the same organization, neither one of which is really adapted to current usage patterns. How did you like it? We're using it via an executable process engine at my current company on a project that's not yet in production, so I'm still on the fence. I have no idea if anyone from the "business" side will ever look at these diagrams, and if it's just the developers looking at them, then why not look directly at the code with the support of a modern IDE?
It works well for business processes, e. The tools I used generated a system using storage-backed messaging between every step for reliability, and then I could plug in a UI or an integration where needed, and generating monitoring screens to illustrate where in the process things are, cycle times, etc etc. If you use it like that, as a config language you can use to drive creation of other things, it can work well, and it's a pretty mature standard, so it can describe lots of possibilities.
My favorite quote: "There was a tendency for informants in large organizations who did not themselves use UML, or who used it selectively, to assume that colleagues in other roles were likely to use it more. I I should say we have used UML class diagrams to build object oriented systems. The class diagrams are something a reasonably sophisticated, but non-programmer, person can understand, so they can participate in the design phase.
Of course there's lots that comes after that design phase, but it set the stage. In case it's of interest, the things we were modeling were bilingual dictionaries, and morphology and phonology linguistics , all of which had a ton of structure we needed to model.
There was a big UML fashion in the company where I work, they even hired a specialist in the subject, did training. And a few years later the specialist left, and no one made UML anymore. This fall was impending. The software components were invented faster than their representation of business components. I remember facing this dilemma early on in s. A JSP did serverside logic as well as Frontend.
UML failed because it kind of sucks, right? I like drawing dataflow when mapping integrations in IT projects out with UML flow diagrams, such as this[0]. But other than that I have never seen anyone use them. I could never find a use. In my college years I've been told a lot of things by my profs.
I could never see most of those things happening but always assumed that they're smarter so they must know what they're talking about. It's kind of satisfying but also profoundly sad that they were both wrong and failed to instill a reflex of questioning authority in their students.
All it added was some meaningless documentation that looked impressive but got out of date approximately immediately after the first class was implemented. The one great thing that came out of UML was sequence diagrams.
I don't recall sequence diagrams being a thing before UML, but they are actually very useful for describing interaction flows. What UML did was to provide software engineers with a common language when illustrating designs on a whiteboard.
I guess there wasn't any money in stopping there, so they had to write a spec and them have very expensive software being built to support this vision. TruthWillHurt 6 months ago prev next [—]. It's alive and well in enterprise projects where Solution Architects need to micro-manage frequently-replaced, Acceptance-Criteria-driven, non-thinking contractors.
Other people in this thread have expressed it, but the reason it's not useful is because most developers are doing something like UML, but it's not UML - so you get none of the benefits of the Unified part. When I see a weird, cobbled together diagram of bits of code the creator thinks defines the state, I have gained nothing of value from viewing the diagram. In my experience, when I see a good UML diagram I know I am seeing a picture of how someone thought something was going to work before they or more likely someone else actually built it.
It might or might not accurately reflect how the code actually works. In particular constraints the diagram claims exist may or may not actually be enforced in the code. I don't agree with the authors use of masala as a cultural appropriation. Using 'masala diagrams' to derogatorily describe software modeling is totally unnecessary.
Why not simply call them blended diagrams or milkshake diagrams or literally anything else that describes a combination of stuff. Picking masala is totally out of context and isn't productive in the year , lets not associate race with opinion.
There's a impedance mismatch between UML and actual programming languages. Idiomatic python is different from idiomatic java, and trying to make UML as it was originally intended, to be a detailed, formal specification of a program, is quite at odds with that.
UML died alongside the waterfall method. UML, especially defining the method names et al, before you coded anything was an extreme of the waterfall method. I think generating UML from code could have been useful. But I was much more likely to grasp more of the system from a paragraph or two or well-written text. Well-written UML rarely helped. Roughly sketched boxes with arrows and a bit of text are the most useful. UML has a few good parts: sequence diagrams or use case diagrams, for instance.
TheMiller 6 months ago prev next [—]. Well, I still use some UML diagrams fairly often. Not so much for permanent or comprehensive system documentation, but to help me think through specific features or behaviors, and communicate these designs to others. I usually use a smallish subset of UML, because this usage doesn't require deep details. May I ask you what were the reasons you abandoned visual tools? My entire experience with UML was as a high school aged kid who'd just found out about it, but despite my best internet searching, could find absolutely no resources on learning or using it.
So I just gave it up and this post is pretty much the first I've heard about it since c. I've been at it 8 years and never actually seen anyone use it, so I think of it as a relic of an era before my time.
I don't really agree with the premise that this is a big tragedy though. There's a danger of getting carried away with the analogy to traditional engineering but the cost of changing things in software is much lower, so exploratory work is much more viable. The problem I found was that no matter how careful we were in drawing the UML there was always one box on the diagram that turned out to be the "pandora box".
This is what happens when writing documentation owuld take the same or more time than writing code. We all see that most "no-coding" auto generating approaches to software development did not work except for simple solutions, and the irony was that the people who had time and manpower for uml where the one with most complex need of software. Marazan 6 months ago prev next [—]. UML's problem is that it is boxes-and-lines.
The trouble with boxes-and-lines is that they work fine for small problems and collapse in a mess of overlapping nonsense for complex situations. This is not a UML specificthing. Any visualisation that is boxes and lines that is not a strict acyclic single parent heirachy is doomed to failure for anything complex. Ironically, UML diagrams are still very useful for their immediate purpose, whatever that is. I frequently use timing diagrams just for my own sake because having to articulate something always adds clarity, showing you where you were handwaving something in your head.
It's the draw. Past a certain scale it just seems easier to read text than visual diagrams, and since apps have tended to get more complex over time, we're reaching that scale more often. I've worked at two companies that started with database schema diagrams, but gave up on it.
They got too complex to be useful, and people stopped looking at them. ThomPete 6 months ago prev next [—]. Whenever my venture studio briefs developers with a new product that needs to be developer we do so in what we call a high definition UML.
Which contains all the logic but centered around fairly high definition ui wireframes, sometimes even design. It's the best method we have found so far to brief developers and for them to follow. The problem with UML is that it could only represent certain functionality It was an extra step. It was much more useful for analyzing and diagraming code, but that too was limited by whatever analysis was being done to generate UML. Rational Rose was the most expensive, worst piece of software I've ever had to use.
It made me completely lose faith in formal design methods as a process, both because the tool sucked, but if the gurus of professional engineering did their best and produced junk, you lose faith. TheJoYo 6 months ago prev next [—]. GitLab supported Mermaid. That showed the most promise for a practical use of UML. I have no idea what that article is trying to get at about multi-dimensional diagrams. I can make masala in UML, there's literally nothing stopping me.
Fortune magazine predicted this back in They did a study that correlated the growth of developers graduating from college was either flat or linear. The growth of computing needs was exponential.
The end result of would be an exponential decrease in discipline in software as amateurs, hackers, trades people and what not necessarily fill the void. There is no other outcome. The challenge is for those areas such as military arsenals, power grids, healthcare and other safety domains to firewall off from the undisciplined masses and enforce discipline.
However, Fortune pointed out that capitalism doesn't reward safety when its cheaper to hire good lawyers and litigate. So Fortune also predicted an explosion in tort and tort lawyers. Verner Vinge wrote about this in his novels. He supposed that rationalization will ensue and that undisciplined code will be seen as security through obscurity, a Gordian knot of convolution.
One possible scenario is more-or-less Skynet were a few computing centers replace millions of devices. This makes sense from a capitalism perspective and governments can a few tightly controlled central services.
So those are the choices given human nature. What's not a choice is an increase in discipline because, you know, human nature. This couldn't be further from the truth. FpUser 6 months ago prev next [—].
Rational was set to conquer the world. Never good idea. However I still use some of their ideas and StarUML diagramming tool to help document preliminary design, use cases, deployment etc. It makes communicating to non tech persons way simpler. I use UML now just to make sense of the huge complexity in code front end dev activity charts for logic, sequence charts for debugging, state distances for UI states.
I have found it invaluable. I started college back in I saw uml from day one. Never actually used it outside college. We used a lot of those tools that can generate diagrams from code and vice versa, but I personally never liked it.
I personally have adopted sequence diagrams in explaining processes to experts in non-programming fields with great success. Can't imagine using UML in daily coding practice, though.
0コメント