каковы старшие значащие недостатки использования UML?
Если Вы объявляете метод в классе-потомке, который имеет то же имя как метод в классе предка тогда, Вы скрываете те методы предшествования — значение, если у Вас будет экземпляр того класса-потомка (на который ссылаются как тот класс), тогда, то Вы не получите поведение предка. Когда метод предка будет виртуальным или динамичным, компилятор даст Вам предупреждение.
Теперь у Вас есть один из двух вариантов подавить то предупреждающее сообщение:
- Добавление ключевого слова повторно представляет , просто говорит компилятору, что Вы знаете о сокрытии того метода, и это подавляет предупреждение. Можно все еще использовать , наследовался , ключевое слово в рамках реализации того убывало метод для вызова методов предшествования.
- , Если метод предка был виртуальный или динамичный тогда, можно использовать переопределение . Это имеет добавленное поведение что, если к этому объекту-потомку получат доступ посредством выражения типа предка, то вызов к тому методу все еще будет к порожденному методу (то, которое тогда может дополнительно позвонить предку до [1 118], наследовалось ).
Так различие между [1 119] переопределение и повторно представляет , находится в полиморфизме. С [1 121] повторно представляют , если Вы снимете объект-потомок в качестве родительского типа, затем назовите тот метод, Вы получите методы предшествования, но если Вы получите доступ к нему порожденный тип тогда, то Вы получите поведение потомка. С [1 122] переопределение Вы всегда получаете потомка. Если методы предшествования не были ни виртуальные , ни динамичный , то повторно представляют , не применяется, потому что то поведение неявно. (На самом деле Вы могли использовать помощника класса, но мы не пойдем туда теперь.)
Несмотря на то, что заявил Malach, можно все еще звонить , наследовался в повторно представленном методе, даже если родитель не был ни виртуальный , ни динамичный .
По существу повторно представляют, точно так же, как переопределение , но оно работает с не - динамичный и не - виртуальный методы, и это не заменяет поведение, если к экземпляру объекта получают доступ через выражение типа предка.
Дальнейшее Объяснение:
Повторно представляют , способ передать намерение к компилятору, что Вы не совершали ошибку. Мы переопределяем метод в предке с переопределение ключевое слово, но это требует, чтобы методы предшествования были виртуальные или динамичный , и что Вы хотите, чтобы поведение изменилось, когда к объекту получают доступ как класс предка. Теперь войдите , повторно представляют . Это позволяет Вам сказать компилятору, что Вы случайно не создали метод с тем же именем как виртуальные или динамические методы предшествования (который был бы раздражающим, если бы компилятор не предупредил Вас о).
8 ответов
The biggest one is that it's yet another layer of red tape that gets in the way of just $#%$#% coding the thing and making it work.
The fact that people use it to "model software for business requirements", as you put it, and other such process-oriented claptrap. UML started out as a conventionalised way for programmers to communicate software to other programmers in a pictorial form. In that sense it's just formalised napkin-scribbling - and as such it is very effective. You can draw a UML class diagram on a whiteboard and I can understand it without quibbling over notation.
But somewhere along the line someone got the idea that a drawing notation could somehow be a process in it's own right, or at least a formal part of a larger process. And that's just silly. UML diagrams are a fine way to illustrate books, and quite useful as a means for engineers to scribble ideas back and forth. But that's where it should have ended.
I can say at least three:
- It takes a lot of time to keep the diagram reasonable and synchronized with the actual code. UML diagrams don't run, but require a lot of time. So they are good only if your organization size can manage them
- You cannot represent every condition in a sequence diagram. It's impossible if you want to deliver. So state diagrams should convey basic facts, not all the possible outcomes.
- Good UML software costs money and it takes some time to master properly.
So, I think UML is good as a complementary documentation role, and only if the size of your organization allows it.
Solutions... well, in the end, diagramming is just a way to convey high level information to another person, in space or time (e.g. could be you in some year time). Extreme Programming shifts the burden of information retrieval from dead tree to living brain. Of course, it assumes that the living brain never forgets, and never quits. Extreme programming uses redundancy to reduce the impact of such occurrences. In a large company, a strong layoff round could wipeout entire teams, so storing information into brains can be risky. On the other hand, large companies have human power to waste, hence the diagramming.
Also, as WDuffy points out, if you are a designer, and you have to communicate to a team of programmers what they have to implement, it's much easier to use a UML diagram. Of course, a small company with a small team has generally small goals, and you can organize people with a different style. A small company UMLing will only produce UML diagrams of their revolutionary product, and then it will be bankrupt.
UML is not good nor bad. It can be a good tool, but it must be used in the proper context.
Lacking features?
well, I found that UML is strongly aimed at an Object Oriented vision of the world. Our company mainly developed in python, with a strong focus on module level routines. Objects were lightweight data containers, but all the logic was done at the module level. It's difficult to properly model this implementation style at the UML level, unless you resort to some "hacks" in the terminology. I guess it's difficult to model in UML for functional or procedural languages.
Another thing I find annoying is the assumption of use case modeling as a diagram. My experience is that the best way to convey a use case is to write a short story or a short code tingling the feature you want to convey. The story should be short, one page maximum. Этот подход имеет два преимущества: если ваш рассказ представляет собой письменную прозу, команда вопросов и ответов может легко прочитать и протестировать его. Если ваша история - это код, вы можете провести ее как функциональный тест и дать ей поработать ночью. Диаграмма не удовлетворяет ни одной из этих потребностей в добавленной стоимости.
Это не Agile
То, что должно было быть последним словом в UML был написан разочарованным студентом «Кандидом Смитом», ну, на самом деле автором Эйфеля Бертраном Мейером.
Одна проблема с UML связана с его универсальностью: вещи в UML не всегда могут быть реализованы непосредственно на целевом языке, или некоторые языки имеют возможности, которые не могут быть выражены в UML. Так что лучше заранее знать язык реализации, что ограничивает его универсальность.
См. Также раздел критики на странице википедии UML :
Раздутие стандартов
Проблемы при изучении и внедрении
Совокупное сопротивление / несоответствие импеданса
Дисфункциональный формат обмена
Another disadvantage of UML is that it tends to overemphasize design, which can lead to 'analysis paralysis' (people over-analyze their problem) and feature creep (loosing sight of the actual problem). A UML design can only take you so far in solving a problem, and you have to be careful to jump into the code soon enough (but not sooner ;-).
Another problem with UML (and big design up front in general) is that it's sometimes hard to anticipate all the nitty gritty implementation problems that you'll run into that may affect your design until you actually start implementing something. Granted, I'm a bioinformatics research programmer that works on small one-man projects, but I don't even believe in any design up front, at least for small projects. I believe in the following:
Make it work. (Just get a prototype up and running that has all the basic functionality, no matter how much it sucks. This forces you to see all the little nitty gritty details that might not come through in a formal analysis. Having an actual implementation of your idea makes it easier to see whether the idea was even really worth doing in the first place or whether it should be scrapped altogether.)
Make it right. (Only now, when you have a working prototype and you know that all the nitty gritty implementation problems are at least in principle solvable do you worry about good design. Refactor the heck out of it to follow good programming practices, reduce coupling, do proper error handling, yada yada yada.)
Make it fast. If it's application code, you'd better have proof that you've found the slow part. If it's generic library code, you'd better have good reason to believe that the piece of code could reasonably be the slow part in some use case for the library, i.e. don't optimize a function that noone would ever call in a loop.
Для диаграмм классов в UML имеет смысл использовать их только в том случае, если существует автоматический способ генерации кода непосредственно из диаграммы. Я реализовал такой инструмент редактора UML на основе четырехуровневых мета-уровней, рекомендованных OMG (Object Management Group), и мы добились большого успеха с использованием UML в команде из 5 разработчиков за 2 года, выполнив около 20-30 архитектурных итераций. Диаграмма была корневым артефактом автоматизированной цепочки сборки, оказывая влияние на сотни производных артефактов, API-интерфейсов, сгенерированных документов, DDL, проектов, тестов и т. Д.
Так что сам по себе UML в части диаграмм классов является отличным "языком программирования", если вы на самом деле занимаюсь программированием в нем.
Для диаграмм классов в UML, если они не могут быть переведены в автоматическом режиме, они не работают.