UML все еще рассматривается как жизнеспособный способ зарегистрировать разработку программного обеспечения? [закрытый]
Поместите все JavaScript, внешние CSS, изображения и т. Д. В src/assets
(будет скомпилировано в build/assets)
В вашем index.html: <script src="assets/yourJavascript.js"></script>
Тогда вы можете просто использовать его, как вы описываете. (declare var PrayTimes: any;)
13 ответов
Я отвечаю на новую версию вопроса, в которой UML рассматривается как средство документации. Я также попробую сыграть в UML в качестве инструмента коммуникации, потому что они - одно в одном.
Контекст: Эта перспектива обусловлена моей ежедневной работой архитектора, которому приходится проектировать сотни систем / программного обеспечения. , 10 000 часов + усилий, а также ведение согласованной документации и практик для портфеля систем. Это означает, что мне приходилось много раз сталкиваться с качеством, согласованностью и определением документации.
Резюме: Что еще есть? Конечно, вы можете обсуждать уровни документации, действительно ли UML лучше, чем чтение кода для условной логики? Скорее всего, нет, но в целом реальной альтернативы нет, если проблемное пространство достаточно велико.
Если UML - не что иное, то - это для документации и общения. Такого мнения придерживается "UML Distilled", написанный Мартином Фаулером, который фактически является стандартом для книг по UML. Фаулер, если я правильно прочитал, считает, что UML в первую очередь используется для связи, а документация является статической. Не так много низкоуровневых спецификаций и генерации кода.
IBM, Borland, Microsoft и Eclipse поддерживают UML с помощью больших сложных инструментов. Многие другие более мелкие или целевые поставщики также предоставляют инструменты UML. Я не знаю более принятого / реализованного стандарта диаграмм / моделирования.
Дополнительно рассмотрите альтернативы, какие обозначения диаграмм более распространены? Почему бы не использовать то, что знает большинство людей. Большинство колледжей / университетов, если они преподают какие-либо схемы или моделирование, используют UML. Кроме некоторых стилей потоковой или условной логической диаграммы, нет ничего другого, хорошо документированного и стандартизованного
. Стандартные обозначения даже более важны, чем то, что знает большинство людей. В крупных проектах не всегда можно прочитать код, поговорить с человеком, который его написал, или снова спросить делового партнера, чего он хочет. Вот где стандарты являются ключевыми. Непоследовательное использование вызовет путаницу, и это действительно произойдет, если людям позволят изобретать или добавлять символы неформальным образом. Кроме того, вы не хотите создавать документ и всегда должны объяснять, что вы имели в виду.
Никогда не придумывайте, если у вас тоже нет, что является наиболее вероятной альтернативой UML. Подумайте о каждом новом человеке, который присоединяется к команде или компании. Что означает прямоугольник, стрелка? Может ли эта стрелка соединиться с этим треугольником в этом направлении, а что это значит? По сути, вам нужно изобрести язык / модель для конкретной предметной области. Итак, вам нужна обучающая презентация, учебные пособия, примеры, обзорная работа, расписание тренировок, поддержка изобретенного метода документации и т. Д. Затем, конечно, вы переключаете партнеров по задаче или нанимаете нового человека, и вам придется делать это снова и снова. Позвольте людям сосредоточиться на изучении систем, а не на вашем методе документирования, или, если необходимо, на передаче знаний или навыков, таких как UML. Пусть эксперты сосредоточатся на кодировании и проектировании, а не на изобретении стандарта документации / диаграмм.
Для всех критиков UML Я не живу в башне из слоновой кости или стеклянном пузыре, мне приходится жить с сотнями различных методов документации каждый день, когда люди изобретают их, или я смотрю на технологию следующего поставщика. UML не идеален, но он самый распространенный, достаточно хороший и незаменимый тривиально.
Допустимые дополнительные вопросы:
- Что я должен визуально задокументировать с помощью UML, где могут взять верх комментарии кода?
- Какой диапазон или аспекты более важны?
- Какой может быть согласованный набор артефактов, который работает для мои системы или приложения? (Это важный вопрос, если вы работаете на предприятии с сотнями приложений / систем)
- Где мы храним документацию, чтобы сделать ее доступной для поиска и обнаружения.
Я предпочитаю использовать автоматически сгенерированный UML (исходный код -> UML) для визуализации реализации системы. Я считаю, что статическая документация часто бесполезна, а иногда и вводит в заблуждение.
Мышление - единственный жизнеспособный способ разработки программного обеспечения.
UML иногда рассматривается как действенный способ частично описать дизайн, который вы придумали.
UML - это просто стандартная нотация для представления дизайна, а не процесс или подход.
ИМО, UML потерял большую часть своего имиджа как единственного и всегда лучшего решения для разработки программного обеспечения. Хотя энтузиасты вначале (а некоторые до сих пор) придерживаются мнения, что UML решит проблемы проектирования , и в идеале все должно быть нарисовано с помощью UML. Реальность доказала, что он не намного лучше, чем любой другой вид диаграмм.
ИМО, UML теперь широко рассматривается как то, чем он является на самом деле: стандарт для многих диаграмм, необходимых для анализа и проектирования oo. Это действительно самый популярный стандарт диаграмм. Есть больше инструментов и больше людей знают UML, чем любой другой стиль диаграмм.
UML - это способ визуального представления дизайна, а не сам метод проектирования. Это просто инструмент, который вы используете в своих путешествиях. Насколько мне известно, он по-прежнему довольно распространен в мире разработки программного обеспечения, поскольку является стандартом и может использоваться для эффективной передачи идей между двумя людьми (поэтому его называют языком).
Для меня вопрос звучит немного задним числом ... Я не знаю Я не думаю, что UML предназначен как инструмент для разработки программного обеспечения, а скорее как инструмент для документирования проекта (в процессе).
На мой взгляд, UML может быть ценным инструментом для такой документации, поскольку он стандартизирует ряд представлений по дизайну ... но ни в коем случае не единственно верный. Любой проектный документ, который достаточно ясен и хорошо написан, сделает свою работу.
UML следует использовать в качестве средства связи. Это определенно действенное средство для передачи проектов и дает разработчикам общий язык для обсуждения этих проектов перед реализацией.
Лучший способ документировать свой дизайн - написать чистый код . UML, как и вся другая документация, имеет тенденцию к энтропии.
UML может стать частью процесса проектирования и реализации. Enterprise Architect имеет отличные инструменты для первоначального проектирования. UML терпит неудачу, если он не подкреплен их дополнительными инструментами повторного импорта после настройки для обновления дизайна. Он действительно хорошо отображает вашу текущую структуру и позволяет добавлять детали с точки зрения других диаграмм UML (варианты использования, диаграммы состояний, макеты пользовательского интерфейса и т. Д.).
К сожалению, UML на самом деле не используется в полной мере использовать его потенциал на практике.
UML - это скорее способ визуализировать дизайн системы, а не процесс его выполнения. Хотя способность визуализировать действительно помогает процессу проектирования.
При этом я люблю и использую UML при проектировании не только базовой архитектуры.
Это очень полезно при проектировании, чтобы иметь возможность увидеть, как все части подходят друг другу. все вместе. Во многих случаях при выполнении UML в проекте обнаруживаются архитектурные недостатки еще до того, как начнется кодирование.
Он служит хорошим ориентиром для ознакомления людей с тем, как работает система, и будет полезен, когда вы вернетесь к этому код позже и спросите: «Как я спроектировал это снова?»
В основном, чтобы ответить на ваш отредактированный вопрос, да, полезно задокументировать дизайн системы, потому что многие люди уже знают это, и, как уже отмечалось,
UML, как указал @John Topley, - это просто стандартная нотация для описания аспектов объектно-ориентированного дизайна, поэтому ваш вопрос не совсем понятен.
Лично я найти диаграммы классов как наиболее полезный аспект UML; Я редко забиваюсь о других вещах, так как мне легче написать короткую описательную документацию, объясняющую взаимодействия и поведение. Диаграммы классов, однако, дают разумный обзор архитектуры.
Следует помнить, что не стоит слишком беспокоиться о написании «идеального» (то есть нормативного) UML; Самое главное - убедиться, что люди понимают ваш дизайн. Тем не менее, будьте осторожны, чтобы случайно не злоупотребить обозначениями, потому что это может сбить с толку людей, ожидающих, что вещи будут иметь конкретное значение. Если сомневаешься,
UML - это только метод визуализации некоторых аспектов разработки программного обеспечения. Его нельзя использовать отдельно для документирования дизайна.
Доклад Как представить архитектуру вашего корпоративного приложения с использованием UML 2.0 и др. , проведенный Пауло Мерсоном на JavaOne 2006, описывает различные подходы к документированию архитектуры, как с, так и без UML. Дополнительную информацию можно найти в Подход к документации по архитектуре, представления и не только (V&B) , в которой описывается подход, поддерживаемый Институтом инженерии программного обеспечения (SEI).