Действительно ли UML практичен? [закрытый]
Вот потрясающий / действительно дерьмовый способ расширения нескольких классов. Я использую пару функций, которые Бабель вложил в мой перекодированный код. Функция создает новый класс, который наследует class1, а class1 наследует класс2 и т. Д. У этого есть свои проблемы, но забавная идея.
var _typeof = typeof Symbol === 'function' && typeof Symbol.iterator === 'symbol' ? function (obj) {
return typeof obj
} : function (obj) {
return obj && typeof Symbol === 'function' && obj.constructor === Symbol ? 'symbol' : typeof obj
}
function _inherits (subClass, superClass) {
if (typeof superClass !== 'function' && superClass !== null) {
throw new TypeError('Super expression must either be null or a function, not ' + (
typeof superClass === 'undefined' ? 'undefined' : _typeof(superClass)))
}
subClass.prototype = Object.create(
superClass && superClass.prototype,
{
constructor: {
value: subClass,
enumerable: false,
writable: true,
configurable: true
}
})
if (superClass) {
Object.setPrototypeOf
? Object.setPrototypeOf(subClass, superClass)
: subClass.__proto__ = superClass.__proto__ // eslint-disable-line no-proto
}
}
function _m (...classes) {
let NewSuperClass = function () {}
let c1 = NewSuperClass
for (let c of classes) {
_inherits(c1, c)
c1 = c
}
return NewSuperClass
}
import React from 'react'
/**
* Adds `this.log()` to your component.
* Log message will be prefixed with the name of the component and the time of the message.
*/
export default class LoggingComponent extends React.Component {
log (...msgs) {
if (__DEBUG__) {
console.log(`[${(new Date()).toLocaleTimeString()}] [${this.constructor.name}]`, ...msgs)
}
}
}
export class MyBaseComponent extends _m(LoggingComponent, StupidComponent) {}
29 ответов
В достаточно сложной системе существуют некоторые места, где некоторый UML считают полезным.
полезные схемы для системы, варьируйтесь применимостью. Но наиболее широко используемыми являются Диаграммы состояний, Схемы Действия и Диаграмма последовательности.
существуют многие предприятия, которые клянутся ими и многими, кто напрямую отклоняет их как чрезвычайную пустую трату времени и усилие.
Его лучшее, чтобы не пойти за борт и думать, что является лучшим для проекта, Вы идете и выбираете материал, который применим и имеет смысл.
UML является только одним из методов для коммуникации в людях. Электронная доска лучше.
UML кажется пользе для крупных проектов с многочисленными командами людей. Однако я работал в малочисленных командах, где коммуникация лучше.
Используя схемы UML-esque хорошо хотя, особенно в перспективном проектировании. Я склонен думать в коде, таким образом, я нахожу пишущие большие спецификации трудно. Я предпочитаю записывать вводы и выводы и оставлять разработчиков для разработки бита в середине.
UML полезен двумя способами:
-
Техническая сторона: много людей (менеджер и некоторый функциональный аналитик) думает, что UML является роскошной функцией, потому что код является документацией: Вы начинаете кодировать, после того, как Вы отладите и зафиксируете . Синхронизация диаграмм UML с кодом и analisys вынуждает Вас понять хорошо запросы клиента;
-
сторона управления: диаграммы UML являются зеркалом того, чтобы требовать клиента, который неточен: если Вы кодируете без UML, возможно, можно найти, что ошибка в требует после большого количества часов работы. Схемы, которые UML позволяют Вам находить возможные точки controversal и разрешать перед кодированием =>, помогают Вашему планированию.
Обычно все проекты без диаграмм UML имеют поверхностный анализ, или у них есть короткий размер.
, если Вы находитесь в linkedin СИСТЕМНЫХ ИНЖЕНЕРАХ группы , см. мое старое обсуждение .
По моему опыту:
способность создать и передать значимые схемы кода является необходимым навыком для любого разработчика программного обеспечения, который разрабатывает новый код или пытается понять существующий код.
Знание специфических особенностей UML - когда использовать пунктирную линию, или круговая конечная точка - не совсем по мере необходимости, но все еще хороша для имения.
UML имеет свое место. Это становится все больше важным, когда размер проекта растет. Если у Вас есть длительный проект, то лучше документировать все в UML.
Одной из проблем, которые я имею с UML, является понятность спецификации. Когда я пытаюсь действительно понять семантику конкретной схемы, я быстро заблудился в лабиринте метамоделей и метаметамоделей. Один из коммерческих аргументов UML - то, что это менее неоднозначно, чем естественный язык. Однако, если два, или больше, инженеры интерпретируют схему по-другому, она перестала работать в цели.
кроме того, я попытался задать конкретные вопросы о документе сверхструктуры о нескольких форумах UML, и членам самого OMG, с минимальными результатами. Я не думаю, что сообщество UML достаточно зрело все же для поддержки себя.
Приезжая от студента, я нахожу, что UML имеет очень мало использования. Я нахожу это нелепым, что PROGAMERS должны все же разработать программу, которая автоматически генерирует вещи, которые, как Вы сказали, необходимы. Было бы чрезвычайно просто разработать функцию в Visual Studio, которая могла вытянуть части данных, искать определения, и продукт отвечает на sufficent так, чтобы любой мог посмотреть на него, большой или маленький, и понять программу. Это также усовершенствовало бы его, потому что это возьмет информацию непосредственно из кода для создания информации.
UML полезен, да действительно! Основное использование, которое я сделал из него, было:
- Мозговая атака о путях часть программного обеспечения должна работать. Это делает легким передать то, что Вы думаете.
- Документирование архитектура системы, это - шаблоны и основные отношения ее классов. Помогает, когда кто-то вводит Вашу команду, когда Вы оставите и хотите удостовериться, что Ваш преемник поймет его, и когда Вы в конечном счете забываете то для чего, черт возьми, был предназначен тот небольшой класс.
- Документирование любой архитектурный шаблон, который Вы используете во всех своих системах по тем же причинам точки выше
я только, не соглашается с Michael, когда он говорит, что использование UML для единственного разработчика и/или простого проекта программного обеспечения кажется излишеством ему. Я использовал его на своих маленьких персональных проектах, и документирование их использующий UML сохранило меня много времени, когда я возвратился им семь месяцев спустя и полностью забыл, как я создал и соединил все те классы.
С точки зрения инженера по контролю качества диаграммы UML указывают на потенциальные дефекты в логике и мысли. Делает мое задание легче:)
Я co-taught проект разработки высшего уровня бегу свои прошлые два семестра в школе. Проект был предназначен, чтобы использоваться в продуктивной среде с локальными некоммерческими организациями как оплата клиентов. Мы должны были быть уверены, что код сделал то, к чему мы ожидали его и что студенты собирали все данные, необходимые для удовлетворения потребностей клиентов.
время Класса было ограничено, как было мое время за пределами класса. По сути, мы должны были выполнить обзоры кода на каждой встрече класса, но с 25 студентами зарегистрировался, отдельное время обзора было очень коротко. Инструментом, который мы нашли самым ценным на этих консультациях, был ERD's, диаграммы классов и диаграммы последовательности. И диаграммы классов ERD были сделаны только в Visual Studio, таким образом, время, требуемое создать их, было тривиально для студентов.
схемы передали большую информацию очень быстро. При наличии быстрого обзора проектов студентов мы могли быстро изолировать проблемные области в их коде и выполнить более подробный обзор на месте.
, не используя схемы, мы должны были бы не торопиться для движения один за другим через файлы кода студентов, ища проблемы.
Я квалифицирую свой ответ путем упоминания, что у меня нет опыта в больших (подобных IBM) корпоративных средах разработки.
путь я представление UML и Рациональный Объединенный Процесс состоит в том, что это - больше РАЗГОВОР о том, что Вы собираетесь сделать, чем на самом деле ВЫПОЛНЕНИЕ , что Вы собираетесь сделать.
(Другими словами, это - в основном пустая трата времени)
Я вижу диаграммы последовательности и схемы действия, используемые справедливо часто. Я делаю большую работу с и встроенными системами "в реальном времени", которые взаимодействуют с другими системами, и диаграммы последовательности очень полезны в визуализации всех взаимодействий.
мне нравится делать схемы примера использования, но я не встретил слишком много людей, которые думают, что они ценны.
я часто задавался вопросом, повысился ли Рациональный, хороший пример видов приложений, которые Вы получаете от UML-основанного-на-модели дизайна. Это чрезмерно увеличено в размере, багги, медленный, ужасный...
Я думаю, что UML является полезной мыслью, я думаю, что 2,0 спецификации сделали то, что было однажды ясная спецификация, несколько чрезмерно увеличенная в размере и громоздкая. Я действительно соглашаюсь с выпуском временных диаграмм и т.д., так как они заполнили пустоту...
Обучение использовать UML эффективно берет немного практики. Наиболее важный момент должен связаться ясно, модель при необходимости и модель как команда. Электронные доски являются лучшим инструментом, который я нашел. Я не видел "цифрового программного обеспечения электронной доски", которому удалось получить утилиту фактической электронной доски.
, Что, будучи сказанным мне действительно нравятся следующие инструменты UML:
-
Violet - Если бы это было больше просто, это был бы листок бумаги
-
инструмент Altova UModel - Good для Java и C#, Моделируя
-
MagicDraw - Мой любимый коммерческий инструмент для Моделирования
-
Poseidon - инструмент Decent с хорошим ударом для маркера
- StarUML - Лучший инструмент моделирования с открытым исходным кодом
Выбросьте только, по-моему. UML является большим инструментом для того, чтобы выразить мысли, единственная проблема - когда Вы храните и поддерживаете его, потому что Вы по существу создаете две копии той же информации, и это - то, где обычно дует ветер. После начального раунда реализации большинство UML еще должно быть сгенерировано от исходного кода, это выйдет из моды очень быстро или потребует, чтобы много времени (с ручными ошибками) было в курсе.
UML работал на меня в течение многих лет. Когда я начал, я считал Fowler UML, Дистиллированный , где он говорит, "делают достаточно моделирования/архитектуры/и т.д.".. Просто используйте что Вы потребность !
Я приезжаю в эту тему немного поздно и просто попробую разъяснить пару деталей. Выяснение, если UML полезен как слишком широко. Большинство людей, казалось, отвечало на вопрос от типичного/популярного UML как перспектива рисунка/коммуникационного инструмента.Примечание: Martin Fowler и другой книжный UML чувства авторов UML лучше всего используются для коммуникации только. Однако существует много другого использования для UML. Прежде всего, UML является языком моделирования, которому отобразили нотацию и схематически изображает к логическим понятиям. Вот некоторое использование для UML:
- Коммуникация
- Стандартизированный Дизайн/документация по решению
- DSL (Предметно-ориентированный язык) Определение Модели Определения
- (Профили UML)
- Использование Шаблона/Актива
- Генерация кода
- Модель к Образцовым преобразованиям
, Учитывая использование упоминает выше регистрацию Паскалем, не достаточно, поскольку это только говорит для схематического изображения создания. Проект мог извлечь выгоду из UML, если какое-либо вышеупомянутое является критическими факторами успеха или является проблемными областями, которым нужно стандартизированное решение.
обсуждение должно расширенный из того, как UML может быть закончен уничтожение или относился к маленьким проектам обсудить, когда UML имеет смысл или на самом деле улучшит продукт/решение, как это - когда UML должен использоваться. Существуют ситуации, где UML для одного разработчика мог распознаться также, такие как Приложение Шаблона или Генерация кода.
Универсальный рабочий процесс и DFDs могут быть очень полезны для сложных процессов. Все другое схематическое изображение (ОСОБЕННО UML) имеет, по моему опыту, без исключения, болезненная пустая трата времени и усилие.
Я нашел UML не действительно полезным для очень маленьких проектов, но действительно подходящим для больших.
По существу, действительно не имеет значения, что Вы используете, просто необходимо иметь в виду две вещи:
- Вы хотите своего рода планирование
- архитектуры, Вы хотите быть уверенными, что все в команде на самом деле используют ту же технологию для планирования проекта
, Таким образом, UML просто что: стандарт о том, как Вы планируете свои проекты. Если Вы наймете новых людей, то там, более вероятно, будут знать, что любой существующий стандарт - является им UML, Flowchard, Nassi-Schneiderman, безотносительно - а не Ваш вырезающий внутренний материал.
Используя UML для единственного разработчика и/или простого проекта программного обеспечения кажется излишеством мне, но при работе в более многочисленной команде, я определенно хотел бы некоторый стандарт для планирования программного обеспечения.
Я должен был бы не согласиться, UML используется повсеместно - где угодно, проект в сфере ИТ разрабатывается, UML обычно будет там.
Теперь, используется ли это хорошо , другой вопрос.
, Поскольку Stu сказал, я нахожу, что оба Варианта использования (наряду с описаниями варианта использования) и схемы действия являются самыми полезными с точки зрения разработчика.
Диаграмма классов может быть очень полезной при попытке показать отношения, а также атрибуты объектов, такие как персистентность. Когда дело доходит до добавления когда-либо единственного атрибута или свойства они обычно - излишество, тем более, что они часто становятся устаревшими быстро, как только код записан.
Одной из самых больших проблем с UML является объем работы, требуемый усовершенствовать его, как только код сгенерирован, поскольку существует немного инструментов, которые могут повторно спроектировать UML от кода и немногих все еще, которые делают это хорошо.
Используя UML похож на рассмотрение Ваших ног, когда Вы идете. Это делает сознательным и явным что-то, что можно обычно делать подсознательно. Новички должны думать тщательно о том, что они делают, но профессиональный программист уже знает то, что они делают. Большую часть времени запись самого кода является более быстрой и более эффективной, чем запись о коде, потому что их интуиция программирования настраивается на задачу.
исключение - то, почему Вы оказываетесь в лесах ночью без факела, и оно запускается, чтобы литься дождем - тогда необходимо посмотреть ноги, чтобы не падать. Существуют времена, когда задача, которую Вы взяли, более сложна, чем Ваша интуиция может обработать, и необходимо замедлиться и заявить структуру программы явно. Тогда UML является одним из многих инструментов, которые можно использовать. Другие включают псевдокод, высокоуровневые схемы архитектуры и странные метафоры.
Я полагаю, что UML полезен только для того, что это заставляет людей думать об отношениях между своими классами. Это - хорошая начальная точка, чтобы начать думать о таких отношениях, но это - определенно не решение для всех.
Я верю, что использование UML субъективно к ситуации, в которой работает группа разработчиков.
Используя UML похож на рассмотрение Ваших ног, когда Вы идете. Это делает сознательным и явным что-то, что можно обычно делать подсознательно. Новички должны думать тщательно о том, что они делают, но профессиональный программист уже знает то, что они делают. Большую часть времени запись самого кода является более быстрой и более эффективной, чем запись о коде, потому что их интуиция программирования настраивается на задачу.
Это не примерно, что Вы делаете все же. Что относительно нового найма, кто приезжает через шесть месяцев с этого времени и должен подойти к скорости на коде? Что относительно пяти лет с этого времени, когда все в настоящее время работающие над проектом ушли?
невероятно полезно иметь некоторую основную актуальную документацию в наличии для любого, кто присоединяется к проекту позже. Я не защищаю полноценные диаграммы UML с именами методов и параметрами (Слишком трудный для поддержания), но я действительно думаю, что основная схема компонентов в системе с их отношениями и основным поведением неоценима. Если дизайн системы не изменяется решительно, эта информация не должна изменяться много, как раз когда реализацию настраивают.
я нашел, что ключ к документации является модерированием. Никто не собирается считать 50 страниц полноценных диаграмм UML с проектной документацией, не заснув несколько страниц в. С другой стороны, большинство людей хотело бы получить 5-10 страниц простых диаграмм классов с некоторыми основными описаниями того, как система соединена.
другой случай, где я нашел, что UML полезен, для того, когда старший разработчик ответственен за разработку компонента, но тогда вручает дизайн младшему разработчику для реализации.
Я полагаю, что может быть способ использовать стиль Cockburn рыба UML, бумажный змей и варианты использования уровня моря, как описано Fowler в его книге "Дистиллированный UML". Моя идея состояла в том, чтобы использовать варианты использования Cockburn как помощь для удобочитаемости кода.
, Таким образом, я сделал эксперимент и существует сообщение здесь об этом с Тегом "UML" или "FOWLER". Это была простая идея для c#. Найдите способ встроить варианты использования Cockburn в пространства имен программирования конструкций (таких как класс и внутренние пространства имен класса или путем использования пространств имен для перечислений). Я полагаю, что это могло быть жизнеспособной и простой техникой, но все еще иметь вопросы и нуждаться в других для проверки ее. Это могло быть хорошо для простых программ, для которых нужен своего рода псевдопредметно-ориентированный язык, который может существовать прямо посреди кода c# без любых расширений языка.
проверьте сообщение, если Вам интересно. Пойдите сюда .
UML определенно имеет свое место в отрасли. Представьте, что вы создаете программное обеспечение для самолета Boing или какой-то другой сложной системы. UML и RUP очень помогли бы здесь.
In the end UML only exist because of RUP. Do we need UML or any of its related stuff to use Java/.Net ? The practical answer is they have their own documenation (javadoc etc) which is sufficient and lets us get our job done!
UML no thanx.
UML используется, как только вы представляете класс с его полями и методами, хотя это просто разновидность диаграммы UML.
Проблема с UML в том, что книга основателей слишком расплывчата.
UML - это просто язык, а не метод.
Меня действительно раздражает отсутствие схемы UML для проектов с открытым исходным кодом. Возьмем что-нибудь вроде Wordpress, у вас просто есть схема базы данных, ничего больше. Вы должны изучить api кодекса, чтобы попытаться получить полную картину.
UML определенно полезен, так же как и junit необходим. Все зависит от того, как вы преподнесете эту идею. Ваша программа будет работать без UML так же, как она будет работать без юнит-тестов. Но при этом вы должны создавать UML так, чтобы он был связан с вашим кодом, т.е. когда вы обновляете диаграммы UML, он обновляет ваш код, или когда вы обновляете ваш код, он автоматически генерирует UML. Не делайте только ради того, чтобы сделать это.
Диаграммы UML полезны для сбора и передачи требований и обеспечения того, чтобы система отвечает этим требованиям. Их можно использовать многократно и на различных этапах планирования, проектирования, разработки и тестирования.
Из темы: Использование моделей в процессе разработки на http://msdn.microsoft.com/en-us/library/dd409423%28VS.100%29.aspx
Модель может помочь вам визуализировать мир, в котором работает ваша система, уточнить потребности пользователей, определить архитектуру вашей системы, проанализировать код и убедиться, что ваш код соответствует требованиям.
Вы также можете прочитать мой ответ на следующий пост:
Как узнать «хороший дизайн / архитектуру программного обеспечения»? на https://stackoverflow.com/questions/268231/how -to-learn-good-software-design-architecture / 2293489 # 2293489