Вы все еще используете UML? Как? Зачем? [закрытый]
В Java все переменные, которые вы объявляете, на самом деле являются «ссылками» на объекты (или примитивы), а не самими объектами.
При попытке выполнить один метод объекта , ссылка просит живой объект выполнить этот метод. Но если ссылка ссылается на NULL (ничего, нуль, void, nada), то нет способа, которым метод будет выполнен. Тогда runtime сообщит вам об этом, выбросив исключение NullPointerException.
Ваша ссылка «указывает» на нуль, таким образом, «Null -> Pointer».
Объект живет в памяти виртуальной машины пространство и единственный способ доступа к нему - использовать ссылки this. Возьмем этот пример:
public class Some {
private int id;
public int getId(){
return this.id;
}
public setId( int newId ) {
this.id = newId;
}
}
И в другом месте вашего кода:
Some reference = new Some(); // Point to a new object of type Some()
Some otherReference = null; // Initiallly this points to NULL
reference.setId( 1 ); // Execute setId method, now private var id is 1
System.out.println( reference.getId() ); // Prints 1 to the console
otherReference = reference // Now they both point to the only object.
reference = null; // "reference" now point to null.
// But "otherReference" still point to the "real" object so this print 1 too...
System.out.println( otherReference.getId() );
// Guess what will happen
System.out.println( reference.getId() ); // :S Throws NullPointerException because "reference" is pointing to NULL remember...
Это важно знать - когда больше нет ссылок на объект (в пример выше, когда reference и otherReference оба указывают на null), тогда объект «недоступен». Мы не можем работать с ним, поэтому этот объект готов к сбору мусора, и в какой-то момент VM освободит память, используемую этим объектом, и выделит другую.
16 ответов
Я предпочитаю гибкий adoptation UML (например, эскизы белой доски) по водопад адаптация UML (например, чрезмерные документы тщательно продуманных схем, оттянутых в Visio).
UML все еще полезен для объяснения дизайна кому-то еще. Например, составной шаблон разработки легко объяснить с простыми диаграммами классов (то есть, после того, как Вы будете сделаны с теми интересными аналогиями).
Несколько нарисованных от руки диаграмм классов и диаграмм последовательности удобны для получения быстрого запуска, когда сталкивающийся с новым или старым проектом с классами, замусоренными повсеместно и без достаточно хорошей документации.
Моя команда также успешно использует диаграммы классов для генерации схем базы данных. Возможно, существуют лучшие пути, но это - другой вопрос.
Я решил, что мне нравятся варианты использования стиля Cockburn, как описано Fowler в его книге, озаглавленной "Дистиллированный UML". Мне нравятся они достаточно, что я создал экспериментальный способ встроить их непосредственно в пространства имен C#.
Путем выполнения этого я мог закодировать бизнес или логику UI с точки зрения английского содержания языка вариантов использования бесплатно, не имея необходимость писать любой вид предметно-ориентированного языка. Самое непосредственное преимущество было то, что я улучшил удобочитаемость кода (альбит в очень новом и тайном способе). Это - все еще экспериментальный подход. Однако я полагаю, что это могло быть полезно.
Здесь ссылка на вопрос, который я отправил при попытке найти другие способы сделать то, что я сделал.
Мы используем диаграммы классов UML только для некоторого царапания главным образом в начале проектов, но также и при объяснении нашего собственного кода другим разработчикам. Но это только sratching, для не документирования нашего программного обеспечения.
По моему мнению с этим очень говорят о UML (людьми, журналами), но не совсем столько людей действительно использует его.
Я использую UML для начальных проектов также. После выполнения reqs фазы и вариантов использования (и в UML и в текстовой форме), базовая система размечается как диаграмма компонентов для идентификации единственных компонентов, интерфейсов, а также подсистем.
я использую его для схематического изображения примера использования. не очень еще все же.
Я использую диаграммы классов ежедневно для обсуждения модели, и объекты и схемы. Это действительно отбрасывает DBAs, пока Вы не указываете, что можно получить ERD на основании диаграммы классов путем скольжения всех стрелок к другому концу строк... Неподвижная точка стрелок в том же направлении возражает против Вас. Там, теперь это изображает FK.
существует много структурных и семантических деталей, которые отличаются между двумя типами схем, но преобразование стрелки, кажется, очищает провал в памяти.
Если Вы используете Гибкий, необходимо использовать UML.
Моделирование важно. Если, конечно, больше забавы получить код записи, однако Вы пропадаете впустую, выделяют времени и понятия не имеют, распределяете ли Вы потребительские требования. Вы моделируете для понимания проблемы, которую Вас просят решить, и ускорить время разработки и поставить полезный продукт Вашим клиентам.
Сохраняют золотую металлизацию для переоцененных кабелей Монстра.
Я использую UML в обсуждениях с другими разработчиками. Я часто думаю мне, что я более успешен в передаче информации другим людям с помощью изображений, таким образом, я нарисую диаграмму классов или схему действия на электронной доске при мозговой атаке с остальной частью команды. Другие участники могут потянуть и изменить его, и как только все мы знаем то, о чем мы говорим, мы склонны просто прокручиваться с ним. Мы не беспокоились генерацией кода непосредственно от него (частично, потому что наши инструменты были ужасны), но с другой стороны мы, возможно, чувствовали себя более принужденными, если мы сделали. Те проекты изменились МНОГО начиная с обмена информацией через электронную доску....
Я на самом деле использую UML, чтобы помочь мне визуализировать и продумать проблемы. С этой целью диаграммы последовательности, схемы действия и объектные схемы очень полезны.
Диаграммы компонентов хороши, когда Вы пытаетесь передать программные слои.
Диаграммы развертывания очень полезны для выяснения упаковки и развертывания, а также каналов связи междоузлия.
Диаграммы классов я нахожу наименее полезными, так как большинство IDE может дать Вам фактическую иерархию классов довольно легко.
UML мертв, мертв, мертв: UML Действительно Мертвый, Или Только Каталептический?
Обмен информацией через электронную доску/Документация в порядке. Генерация кода от него? Кому нужно это и для какой?
Я видел, генерировал UML, используемую, чтобы помочь новым наймам надеть дескриптор, что было очень включенной и сложной системой. Так как UML был автоматически сгенерирован от кода, это было всегда актуально, и некоторые люди нашли его полезным.
Я использую UML для начальных проектов и как помощь обсуждению когда говорящий с другими разработчиками. Но вне начального дизайна время потратило попытку быть в курсе, UML не стоит усилия.
См. ТАК: действительно ли UML практичен? еще для некоторых ответов по теме. Это, кажется, что UML все еще полезен для передачи понятий и систем. Люди, кажется, используют его в качестве описания, а не определения. При разделении UML от самой реализации Вы столкнетесь с проблемой, сохраняющей два в синхронизации.
Я всегда использовал UML (или UML ispired) графика как сопроводительная документация. Документы обеспечивают часть вовремя, такую как, "это было нашим исходным понятием о пользователе". Совершенствование документов трудно и было бы только сделано, если мы должны изменить наше определение. Тогда у нас есть другой поспешный выстрел вовремя. UML не был дизайном, но частью процесса проектирования.
я использовал некоторые генерирующиеся инструменты кода, которые использовали UML, но только генерировать начальные тупики. Обычно, как только код был сгенерирован, он развился отдельно из схемы.
Одна проблема с UML состояла в том, что во многих случаях arguements вспыхнул о надлежащем синтаксисе/стиле UML вместо того, чтобы концентрироваться на том, помог ли рисунок клиенту, аналитик или разработчик понимают понятие. Я знаю, что синтаксис важен, когда генерация кода, но я нашел UML, лучше всего используется для понимания понятия.
Мы все еще используем UML. Как другие здесь, я нахожу, что они значительно помогают в коммуникации. Для людей намного легче связаться, когда у них есть визуальные средства (введите популярность PowerPoint). Это особенно верно в начальных фазах проекта, где сценарии как объясненный firebird84 происходят много. Кропотливая сторона к UML является содержанием схем однажды разработчики на кодировании запуска проекта.
Мы не генерируем код прочь их, хотя и я должен все же лично говорить с кем-то, который использовал UML до той степени.
Together / J - хороший ориентир, потому что нет НИКАКИХ усилий для создания UML, он просто присутствует вместе с вашим кодом Java. Интересно посмотреть, использовал ли я UML, когда он был там «бесплатно».
Было ли мне полезно иметь это там? Честно говоря, я нашел его полезным в качестве дополнительного визуального подтверждения и перекрестной проверки того, что дизайн, который я сделал , обретал форму, и в качестве инструмента визуальной каталогизации. Я не думал о конкретной логике или схемах, основанных на схемах. Ну ладно, может, иногда и делал.
Стоило ли это денег? Это заставило меня почувствовать себя хорошо в процессе. Другим это выглядело впечатляюще. Это избавило меня на несколько мгновений от размышлений об инвентаризации того, что у меня было. Это заставило меня больше задуматься о аккуратности и простоте в целом, о том, что каждый объект занимает пространство на экране. Это заставило меня спросить, действительно ли мне нужен этот атрибут или можно сделать его аккуратнее? Иногда это помогало мне «думать в UML».
Мог бы я теперь использовать Together / J, имея дополнительный опыт? Смогу ли я теперь тратить время на создание UML с нуля?
Что ж, когда я смотрю на то, что я на самом деле делаю для проекта, он состоит из написания дизайна пользовательского интерфейса, схем базы данных и протоколов связи, рассмотрения вариантов использования и использования памяти, использования полосы пропускания и безопасности . Фактически почти все, что можно учесть, кроме объектной ориентации / UML. И я не использую Together / J.
Почему?
Это потому, что я усвоил знания, полученные при помощи UML. Теперь я сосредотачиваюсь на достижении экономии времени, пространства и времени в дизайне. Мои проекты сильно ограничены принципами UML, поэтому стоило изучить все эти вещи, но я больше не использую настоящие бумажные диаграммы UML и не мыслю в UML.
UML просто предполагается; данный. А точнее его влияние на дизайн.
То, что у меня сейчас на экране, - это чистый код и данные. У меня также есть чувство достижения. : -)