Каковы преимущества моделирования программных систем по сравнению с выполнением всего этого в коде?

Большинство, если не все ИТ-специалисты, которых я знаю, считают, что полезно моделировать программное обеспечение с помощью UML или других типов диаграмм перед кодированием. (Мой вопрос не о UML, а о графическом или текстовом описании дизайна программного обеспечения.)

Я не уверен в этом. Основная причина: код не лжет. Проверяется компилятором или интерпретатором. Надеемся, что он имеет автоматические тесты и должен пройти статический анализ кода. Если модуль неправильно взаимодействует с другим модулем, это обычно очевидно в коде, потому что вы получаете сообщение об ошибке.

Все это нельзя сделать с помощью диаграмм и других документов. Да, есть инструменты, которые проверяют UML, но все, что я видел до сих пор, очень ограничено. Поэтому эти документы, как правило, являются неполными, непоследовательными или просто ложными.

Даже если сами диаграммы согласованы, вы не можете быть уверены, что код действительно их реализует. Да, есть генераторы кода, но они никогда не генерируют весь код.

Иногда мне хочется одержимости результатами моделирования, исходя из предположения, что код неизбежно должен быть неким непонятным беспорядком, с которым архитекторам, дизайнерам или другим хорошо оплачиваемым людям, которые получают общую картину, не придется сталкиваться. В противном случае это будет слишком дорого. Поэтому все проектные решения должны быть удалены от кода. Сам код должен быть предоставлен специалистам (обезьянам кода), которые могут написать (и, возможно, прочитать) его, но не должны иметь дело ни с чем другим. Это, вероятно, имело смысл, когда ассемблер был единственным вариантом, но современные языки позволяют кодировать на очень высоком уровне абстракции. Поэтому я больше не вижу необходимости в моделировании.

Какие аргументы для моделирования программных систем мне не хватает?

Кстати, я верю, что диаграммы - отличный способ документировать и передавать определенные аспекты разработки программного обеспечения, но это не означает, что мы должны основывать на них разработку программного обеспечения.

Разъяснение:

Вопрос был отложен как неясный. Поэтому позвольте мне добавить некоторые пояснения:

Я спрашиваю, имеет ли смысл использовать (не кодированные) документы, которые моделируют программное обеспечение, как основной источник правды о разработке программного обеспечения. Я не имею в виду тот случай, когда значительная часть кода автоматически генерируется из этих документов. Если бы это было так, я бы рассматривал сами документы как исходный код, а не как образец.

Я перечислил некоторые недостатки этой процедуры, которые заставляют меня задуматься, почему так много людей (по моему опыту) считают ее предпочтительным способом разработки программного обеспечения.

Преимущество программных систем моделирования по сравнению со всем в коде: я могу разместить модель на доске.

Я большой сторонник магии общения на одном листе бумаги. Если бы я попытался разместить код на доске, при обучении нашей системы новым кодировщикам просто не было бы кода на необходимом уровне абстракции, который бы подходил для доски.

Я знаю одержимость моделированием, о которой ты говоришь. Люди делают вещи, потому что так они делали раньше, не задумываясь о том, почему они это делают. Я пришел, чтобы назвать это формализмом. Я предпочитаю работать неформально, потому что за традициями труднее скрывать глупости.

Это не значит, что я не буду время от времени вырывать набросок UML. Но я никогда не буду парнем, требующим, чтобы вы включили документ UML, прежде чем сможете писать код. Я мог бы потребовать, чтобы вы потратили 5 минут и нашли НЕКОТОРЫЙ способ объяснить, что вы делаете, потому что я не выношу существования кода, который понимает только один человек.

Фаулер определил различные способы использования UML людьми, которые он назвал режимами UML . Опасность в том, что все они могут быть использованы для того, чтобы спрятаться от полезной работы. Если вы делаете это для написания кода с помощью мыши, я видел много попыток. Никто не видел, чтобы это действительно работало. Если вы делаете это для общения, вам лучше убедиться, что другие вас понимают. Если вы делаете это для разработки, вам, черт побери, лучше находить и исправлять проблемы во время работы. Если все идет гладко и большая часть вашего времени уходит на то, чтобы стрелки выглядели хорошо, сбейте их и возвращайтесь к работе.

Самое главное, не создавайте диаграммы, которые, как вы ожидаете, будут действительны более суток. Если вы как-то можете, вы потерпели неудачу. Потому что программное обеспечение должно быть мягким. Не тратьте недели на то, чтобы правильно составить диаграммы. Просто скажи мне, что происходит. Если вам нужно, используйте салфетку.

Тем не менее, я предпочитаю кодеров, которые знают свой UML и свои шаблоны проектирования. С ними легче общаться. Пока они знают, что создание диаграмм не является работой с полной занятостью.

Я спрашиваю, имеет ли смысл использовать (не кодированные) документы, которые моделируют программное обеспечение в качестве основного источника правды о разработке программного обеспечения

Нет, это никогда не имеет смысла. Ваш код - ваш основной проектный документ, то есть «основной источник правды о разработке программного обеспечения». Только код описывает, что именно делает приложение, поскольку компилятор берет этот дизайн и создает приложение из него.

Безусловно, используйте диаграммы в качестве дополнительных проектных документов, хотя, если они не генерируются автоматически из кода, остерегайтесь их, рассказывающих реальную конструкцию о другой истории. Если UML плавает на вашей лодке, используйте это. Если нет, используйте что-то еще.

Некоторые люди считают полезным набросать свое мышление в виде диаграммы, прежде чем начинать писать код. Но помните, что дядя Боб сказал по этому поводу:

« Так что, да, временами диаграммы могут быть неуместными. Когда они неуместны? Когда вы создаете их без кода для их проверки, а затем намереваетесь следовать им. Нет ничего плохого в том, чтобы нарисовать диаграмму для изучения идеи ».

Если вы используете UML для изучения дизайна, отбросьте их, когда начнете писать код. Напишите тест, затем напишите некоторый код, чтобы он прошел. Повторение. Таким образом, вы получите проверенный дизайн. UML никогда не сможет предложить вам такой же уровень проверки вашего дизайна.

Большинство, если не все ИТ-специалисты, которых я знаю, считают, что полезно моделировать программное обеспечение с помощью UML или других типов диаграмм перед кодированием.

Я не согласен с тем, что все люди, которых вы знаете, верят в это, но я не думаю, что это обязательно распространено по всем направлениям. В 1970 году Уинстон Ройс знал, что разработка программного обеспечения имеет некоторый уровень итерации между проектированием и действиями кода. В 1992 году Джек Ривз написал, что кодирование - это настоящая дизайнерская деятельность (также обсуждаемая на C2 Wiki ).

Это не означает, что люди пытались создавать инструменты разработки на основе моделей. Существуют инструменты, которые пытаются генерировать код из моделей UML (и не только диаграммы классов, но и связывать вместе различные типы диаграмм и генерировать код из них). Но это не так, по крайней мере из того, что я видел, широко используемые инструменты.

Это также не означает, что вы должны перейти от требований к написанию кода. Существуют определенные проектные решения, которые очень важны для правильного решения на раннем этапе, и некоторый уровень моделирования может быть полезен, чтобы убедиться, что все понимают варианты, их влияние и могут общаться. Некоторые люди (в том числе и я) называют это «программной архитектурой» .

Код не лжет. Проверяется компилятором или интерпретатором. Надеемся, что он имеет автоматические тесты и должен пройти статический анализ кода. Если модуль неправильно взаимодействует с другим модулем, это обычно очевидно в коде, потому что вы получаете сообщение об ошибке.

Это действительно основа некоторых аспектов гибкого моделирования, особенно исполняемых спецификаций и единого источника информации . Я не обязательно согласен с TDD, но идея сделать ваш код и связанные с ним тесты (от модульных до приемочных тестов, предпочтительно захваченных в виде автоматических тестов) единственными источниками правды - хорошая идея.

Даже если сами диаграммы согласованы, вы не можете быть уверены, что код действительно их реализует. Да, есть генераторы кода, но они никогда не генерируют весь код.

Как правило, я думаю, что переход от модели-> кода - это неправильный путь. Вместо этого код должен генерировать модели. То есть инструменты должны быть в состоянии исследовать код и генерировать графические и табличные представления, которые могут быть улучшены по мере того, как инженеры пишут текст вокруг них. И это поколение моделей из кода должно быть неотъемлемой частью процесса сборки и выпуска.

Существуют инструменты, которые в разной степени поддерживают это для разных языков. Учитывая природу языков и парадигм, некоторым это легче, чем другим.

Я перечислил некоторые недостатки этой процедуры, которые заставляют меня задуматься, почему так много людей (по моему опыту) считают ее предпочтительным способом разработки программного обеспечения.

Я не думаю, что эти люди обязательно понимают разработку программного обеспечения и разработку программного обеспечения. Я думаю, что эти люди смотрят на то, что делают другие инженерные дисциплины, и сопоставляют это с тем, что, по их мнению, должны делать разработчики программного обеспечения. Но они игнорируют одно существенное отличие. Другие инженерные дисциплины сначала создают модели и симуляции, потому что создание реального продукта чрезвычайно дорого и отнимает много времени. В разработке программного обеспечения мы можем взять кусочки нашего проекта и создать что-то, что можно протестировать в реальной среде за очень короткое время и с очень небольшими затратами. Экономика очень разная.

Каковы преимущества моделирования программных систем по сравнению с выполнением всего этого в коде?

Если у вас чрезвычайно сложная система программного обеспечения, наличие моделей означает то, что легче понять. Это другой уровень абстракции, который помогает людям понять различные аспекты вашей системы. Это одна из причин того, что для каждого языка моделирования или обозначения существует так много разных языков моделирования и разных типов моделей, что позволяет различным заинтересованным сторонам быстро и легко понять концептуальную систему программного обеспечения.

Я спрашиваю, имеет ли смысл использовать (не кодированные) документы, которые моделируют программное обеспечение, как основной источник правды о разработке программного обеспечения. Я не имею в виду тот случай, когда значительная часть кода автоматически генерируется из этих документов. Если бы это было так, я бы рассматривал сами документы как исходный код, а не как образец.

Множество некодовых документов полезно в качестве чертежей . То есть «правда» дизайна должна следовать этому направлению. Это способ моделировать элементы, которые должен выполнять дизайн. Вы могли бы назвать их документами требований, но это может быть слишком сильно во всех примерах, которые я мог бы привести. Я использовал PlantUML через PlantText.com производить их.

• Диаграммы сценариев использования могут показать предполагаемые функции и взаимодействия с пользователями или внешними системами.

• Диаграммы действий могут показывать бизнес-процессы, которые необходимо поддерживать программному обеспечению.

• Диаграммы состояний могут отображать предполагаемую динамику на веб-сайте:

• Шаблоны Gang of Four представлены в виде статических и динамических моделей. Например, Memento:
  
  

Я перечислил некоторые недостатки этой процедуры, которые заставляют меня задуматься, почему так много людей (по моему опыту) считают ее предпочтительным способом разработки программного обеспечения.

Если вас интересует какая-то реальная информация об использовании UML вне вашего опыта, были проведены некоторые исследования (я попытался найти ссылки на статьи, не относящиеся к платным системам):

• Петре, Мариан (2013). UML на практике . В: 35-я Международная конференция по программной инженерии (ICSE 2013), 18-26 мая 2013 г., Сан-Франциско, Калифорния, США, стр. 722–731.
• Н. Мангано, Т. Д. ЛаТоза, М. Петре и А. ван дер Хук (2015). Как разработчики программного обеспечения взаимодействуют с эскизами на доске . В кн .: Транзакции IEEE по программной инженерии, вып. 41, нет. 2, с. 135-156.
• Эндрю Форвард и Тимоти С. Летбридж. 2008. Проблемы и возможности для разработки программного обеспечения, ориентированного на модель, и кода: обзор профессионалов программного обеспечения . В материалах международного семинара 2008 года по моделям в программной инженерии (MiSE '08). ACM, Нью-Йорк, Нью-Йорк, США, 27-32.

Мы, разработчики, любим использовать изображения, чтобы объяснить наш мир, поэтому вот один из них, посвященный производству автомобилей:

• Автомобиль является результатом производственной цепочки, то же самое для кода (конечно, добавьте процесс развертывания).
• Проектная документация автомобиля такая же, как и проектная документация программного обеспечения.

В наших мирах часто бывает так, что те, кто задумывает и составляет проектный документ, совпадают с теми, кто создает код. Это не верно в других областях. Однако это не означает, что вы действительно можете получить тот же уровень качества, делая их все вместе.

Делая эти документы первыми без кодирования (исключая что-либо вроде подтверждения концепции быстродействия, ...):

• Вы обязательно должны подумать, прежде чем делать, кодирование, когда вы знаете, что вы должны сделать, это легко.
• Вы можете сосредоточить внимание более опытных людей на самой сложной части вашего программного обеспечения: дизайн, алгоритм / математика - любые, кроме очень специфических целей (встроенные, в реальном времени, сборка).
• Вы можете делегировать менее опытным людям хорошую часть процесса кодирования, в то время как более опытные люди сосредотачиваются только на наиболее важной части, которой необходим уровень их квалификации. Эти менее опытные люди узнают много нового об этом.
• Вы можете обсуждать с не-айтишниками образ вашего проектного документа, в то время как если бы у вас был только код, вам пришлось бы извлекать изображение того, что вы делали, со всем риском что-то забыть (где-то забытый слушатель ...) См. Ответ CandiedOrange для получения дополнительной информации о коммуникации.
• Когда вам нужно сделать так, чтобы ваше программное обеспечение развивалось, вы можете лучше предвидеть последствия.
• Проектирование позволит легко сократить часть вашего программного обеспечения и одновременно разрабатывать его.
• Писать эти проклятые юнит-тесты будет гораздо проще, когда вам не нужно беспокоиться о том, чтобы охватить все случаи при их кодировании, в подходе TDD кодировать тест до того, как код будет легким.
• ...

Примечание: эти утверждения предполагают, что код действительно отражает дизайн, и они оба идут в ногу со временем ...