Почему мы не можем захватить дизайн программного обеспечения более эффективно? [закрыто]

14

Как инженеры, мы все "проектируем" артефакты (здания, программы, схемы, молекулы ...). Это действие (дизайн-глагол), которое дает какой-то результат (дизайн-существительное).

Я думаю, что мы все согласны с тем, что дизайн-существительное отличается от самого артефакта.

Ключевым видом деятельности в программном бизнесе (на самом деле, в любом бизнесе, где необходимо улучшить конечный артефакт продукта) является понимание «дизайна (существительное)». Тем не менее, как сообщество, мы, похоже, почти полностью терпим неудачи при его записи, о чем свидетельствует количество усилий, которые люди прикладывают для повторного обнаружения фактов о своей кодовой базе. Попросите кого-нибудь показать вам дизайн своего кода и посмотреть, что вы получите.

Я думаю, что дизайн программного обеспечения имеет:

  • Явная спецификация того, что должно делать программное обеспечение и насколько хорошо оно это делает
  • Явная версия кода (эта часть проста, у всех есть)
  • Объяснение того, как каждая часть кода служит для достижения спецификации (например, связь между фрагментами спецификации и фрагментами кода)
  • Обоснование , почему этот код так , как это (например, почему конкретный выбор , а не другой)

То, что НЕ является дизайном, - это особый взгляд на код. Например, [не указывать конкретно] диаграммы UML не являются проектами. Скорее, это свойства, которые вы можете получить из кода, или, возможно, свойства, которые вы хотели бы получить из кода. Но, как правило, вы не можете получить код из UML.

Почему после 50 с лишним лет создания программного обеспечения у нас нет регулярных способов выразить это? (Не стесняйтесь противоречить мне с явными примерами!)

Даже если мы это сделаем, большая часть сообщества, кажется, настолько сосредоточена на получении «кода», что дизайн-существительное в любом случае теряется. (ИМХО, пока дизайн не станет целью разработки, с артефактом, извлеченным из проекта, мы не собираемся обойти это).

Что вы видели в качестве средства для записи дизайна (в смысле, я описал это)? Явные ссылки на статьи были бы хорошими. Как вы думаете, почему конкретные и общие средства не были успешными? Как мы можем изменить это?

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

РЕДАКТИРОВАТЬ 2011/1/3: Один из потоков ответов намекает на то, что «документация» (предположительно, текстовая, в частности неформальная) может быть адекватной. Думаю, мне следует уточнить, что я не верю в это. Инструменты CASE появились на сцене начиная с 80-х годов, но ранние инструменты в основном просто захватывали пиксели для диаграмм того, что вы нарисовали; в то время как инструменты были, возможно, коммерчески успешными, они действительно были не очень полезны. Ключевым моментом было то, что, если дополнительные «конструктивные» артефакты формально не интерпретируются, вы не сможете получить серьезную помощь инструмента. Я полагаю, что то же самое относится к любой долгосрочной полезной форме захвата дизайна: если у нее нет формальной структуры, она не будет иметь никакого реального использования. Текстовые документы в значительной степени не проходят этот тест.

Ира Бакстер
источник
1
Согласился на UML - инструмент коммуникации в лучшем случае, способствующий описанию дизайна, но не сам по себе дизайн. В худшем случае UML - это графический исходный код.
Steve314
количественно «насколько хорошо это делает»
Стивен А. Лоу
Когда я строю системы, я отвечаю множеству «нефункциональных» требований: написано на этом языке, использует эту базу данных, обрабатывает записи 1E10 со средним временем отклика 100 мс, ... Вы не можете оставить их вне спецификации. (Без нефункциональных требований вечный цикл - это адекватная программа для любой функциональной спецификации). Весь мой смысл в захвате «дизайна» заключается в обработке другого нефункционального требования: «ремонтопригодность».
Ира Бакстер
Ваше обсуждение выглядит интересно, но я до сих пор не уверен, о чем конкретно идет речь. Как вы думаете, вы могли бы попытаться привести что-то вроде конкретного примера или что-то, чтобы уточнить, что именно вас интересует. Я думаю о чем-то вроде примера БПФ, где вы могли бы дать полную картину 4 пунктов в вашем вопросе, как вы их видите, и, возможно, какие вещи вы хотели бы сделать с полученными результатами.
n1ckp
Я понятия не имею, почему эта проблема, но это тема Фреда Брукса «Дизайн дизайна» . (Извините, если вы уже знакомы.) Он обсуждает примеры из программирования и архитектуры. Он особо отмечает, что получение обоснований (как для дизайна, так и для отклоненных альтернативных проектов) действительно полезно и неэффективно для современных инструментов.
Пол Д. Уэйт

Ответы:

8

Я думаю, что есть несколько причин, почему мы все еще не очень хороши в этом.

  1. Люди долгое время, хотя программное обеспечение было похоже на дома, и использовали процессы и идеи из строительства. «Архитектор программного обеспечения» - это название, которое хотели все программисты. За последние десять лет архитектор программного обеспечения практически вымер. Идея каскадных процессов, когда у вас сначала есть архитектор, говорящий о том, как должно работать и выглядеть программное обеспечение, а затем заставляет людей составлять диаграммы того, как оно должно быть сконструировано, и, наконец, заставляет обезьяну кода реализовывать эти приятные рабочие потоки / диаграммы UML для спецификации, эта идея заключается в том, что сейчас широко высмеивают. Так что на самом деле вся индустрия в течение 40 лет шла по неверному пути.

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

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

  4. Следовательно; Если у вас есть успешная и точная модель программного обеспечения, эта модель будет эквивалентна программному обеспечению. Что делает все усилия бессмысленными, что, в свою очередь, подтверждает пункт 1 выше: моделирование программного обеспечения гораздо менее полезно, чем считалось ранее. Вместо этого лучше извлечь данные о программном обеспечении из кода. Создание модели UML из того, как на самом деле выглядит код, гораздо более поучительно, чем создание модели UML и попытка реализовать эту теоретическую модель.

Леннарт Регебро
источник
2
Не согласен с твоим последним пунктом. Да, это будет скорее эквивалентно программному обеспечению, но все же легче перерисовать модель, чем реорганизовать реальное программное обеспечение, когда (не если) вы обнаружили, что что-то не так уж и хорошая идея. Я бы не стал недооценивать важность этапа проектирования.
Йорис Мейс
1
@Joris Meys: Проблема в том, что вы не будете знать, что и что не является хорошей идеей, пока не осуществите ее. (За исключением простых случаев, но в любом случае вы не будете широко использовать диаграмму UML). Также не стоит переоценивать, насколько сложно рефакторинг кода. Я рекомендую прочитать книги Кент Бекс по XP и Test Driven Design.
Леннарт Регебро
@Lennart: спасибо за совет
Йорис Мейс
2
@ Леннарт: Разница между вами и Джобом в том, что вы, похоже, согласны с тем, что выраженная каким-то образом спецификация может быть необходимой, хотя я не знаю, как это делает ваш набор программируемых в настоящее время абстракций. Но представьте, что мне нужна программа обработки сигналов, которая извлекает основные частоты. Обратите внимание, я не предложил как. Вы можете решить использовать быстрое преобразование Фурье, и я обязательно найду следы по всему коду, который реализует биты FFT. Но где тот факт, что вы решили использовать явно записанный БПФ? Я верю, что вам это нужно, если только ваши читатели не знают все.
Ира Бакстер
1
@ Ира Бакстер: Как насчет «Мы решили реализовать обработку сигналов с помощью БПФ»? Знаете, в исходном коде есть комментарии. И я также могу написать это в файле README. Явным выражением спецификации является код. Текстовые строки типа «Мы решили реализовать его с помощью БПФ» не являются ни явными, ни оформленными в смысле вашего исходного поста. Это документация реализации. Вы , кажется , оказались в аргументативной режиме, но я не понимаю , что вы пытаетесь спорить против.
Леннарт Регебро
5

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

  • CUBRANIC, D., MURPHY, GC, SINGER, J., BOOTH KELLOGG, S. Hipikat: проектная память для разработки программного обеспечения. Труды по разработке программного обеспечения 31, 6 (2005), 446–65.
  • TANG, A., BABAR, MA, GORTON, I., HAN, J. Обзор использования и документации обоснования архитектурного дизайна. В работе 5-й рабочей конференции IEEE / IFIP по архитектуре программного обеспечения (2005).
  • RAMESH, B., POWERS, T., Стаббс, C., и Эдвардс, M. Реализация требований прослеживаемости: тематическое исследование. В работе Международного симпозиума по разработке требований (Йорк, 1995).
  • HORNER, J., ATWOOD, ME. Обоснование дизайна: обоснование и барьеры. В материалах 4-й конференции Северных стран по взаимодействию человека с компьютером: изменение роли (Осло, Норвегия, 2006 г.).
  • КЛЕЛАНД-ХУАН, Дж., СЕТТИМИ, Р., РОМАНОВА, Э., БЕРЕНБАХ, Б., И КЛАРК, С. Лучшие практики для автоматизированного отслеживания. Компьютер 40, 6 (июнь 2007 г.), 27–35.
  • ASUNCION, H., FRANÇOIS, F., И TAYLOR, RN Полный инструмент прослеживаемости промышленного программного обеспечения. В Процессе 6-го Совместного Совещания Европейского Сообщества по программному обеспечению Eng Conf и Международного симпозиума ACM SIGSOFT по основам разработки программного обеспечения (ESEC / FSE) (Дубровник, 2007).

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

С другой стороны, моя собственная работа над Arcum была для программистов средством выразить IDE использование сквозных идиом дизайна. После этого программисты могут преобразовать свой исходный код для использования альтернативных реализаций:

Кстати, Arcum также связан с вашей работой в DMS.

Макнейл
источник
1
+1 за это. RT - это еще не все, но это один из нескольких положительных шагов на пути к решению проблемы вместо того, чтобы оправдывать ее прежними оправданиями.
Aaronaught
2

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

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

В этом свете мне показалась интересной следующая статья (я встречал ее в другом контексте, когда искал программное обеспечение для графов, но тем не менее ...). Графический подход для описания дизайна имел смысл для меня, хотя, на мой взгляд, это только часть дизайна. Интересно, что этот подход дает основу для понимания и рефакторинга проектов (в отличие от рефакторинга программного обеспечения), как указано в следующих статьях:

Существует множество других подходов для описания (части) дизайна, таких как структурированный дизайн (HIPO Charts) или интегрированный дизайн программы , шаблоны проектирования , ...

Тем не менее, пока нет установленного отраслевого стандарта, вряд ли найдется «обычный» способ выразить это. Даже после 50+ лет. И, честно говоря, если ваша компания найдет хороший способ выразить дизайн, поделитесь им со всем миром?

Йорис Мейс
источник
Если ваша компания найдет хороший способ сделать это, программисты быстро расскажут всем остальным. :-)
Леннарт Регебро
Я думаю, что вы упускаете мою точку зрения об UML (и любой другой «единой» нотации). UML-before-code - это ограничение на то, как вы хотите построить программное обеспечение. Как и все другие обозначения (да, я видел много таких, я некоторое время был рядом). Учитывая ограничение, возможно, возможно создать код, отвечающий этому ограничению (метод шутки: создайте все возможные программы и проверьте, какие из них соответствуют ограничению, выберите одну из них). В этом смысле вы можете «генерировать код из UML». Но (если мы будем придерживаться диаграмм классов), этот код не будет реализовывать функцию, которую вы хотите ...
Ира Бакстер
... и от этого страдают и большинство других схем обозначений, которые на самом деле не отражают спецификацию того, что должна делать программа. Они также не дают ничего похожего на обоснование; почему ваша UML-диаграмма имеет такую ​​форму? Какую часть кода я могу изменить, не нарушая диаграмму? Могу ли я измениться таким образом, чтобы не повредить намерению, стоящему за графиком?
Ира Бакстер
@ Ира: После посещения твоей веб-страницы мне стало понятнее. Но я должен признать, что семантическая дискуссия на высоком уровне по этим вопросам выходит за рамки моей компетенции. Тем не менее, если вы рассматриваете реальный код как часть проекта, то где же настоящий артефакт? UML - или любая другая нотация - по моему скромному мнению является планом структуры кода, и это то, что мне нравится называть частью дизайна. На самом деле больше, чем фактический код. возражать против части . Это не дизайн, но все же существенный вклад в это. опять же, по моему скромному мнению. Обоснование и т. Д. Могут быть добавлены к этому, как объяснено.
Йорис Мейс
@Joris: Большинство схематических обозначений могут рассматриваться как проекции (предполагаемые артефакты) из кода (по крайней мере, после его завершения) или могут рассматриваться как руководство для построения кода (план). Есть много возможных диаграмм (некоторые перечислены в вашем ответе). Какие из них имеют основополагающее значение для вашего кода, а какие просто несчастные случаи? Блок-схемы являются биграммами, поэтому они должны соответствовать требованиям; все же я уверен, что блок-схемы некоторого фрагмента кода не будут считаться частью его дизайна. Итак, что является фундаментальным? Что случайно?
Ира Бакстер
2

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

Каждый человек в моей команде имеет диплом инженера ... в основном EE или CE. Инженерия учит вас дизайну как часть учебной программы.

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

Pemdas
источник
Так какой конкретный метод написания требований и проектных документов вы используете? (Я посмотрел на вашу биографию и ожидал увидеть кого-то из оборонительного пространства и был удивлен). Я полагаю, под требованиями вы подразумеваете какой-то текст на естественном языке? ... если так, у вас нет аргументов о них? (Я различаю требования естественного языка от формальных спецификаций). Они завершены? А проектная документация? Они полностью обновлены для текущей системы доставки? Я согласен, что многие так называемые программисты и разработчики программного обеспечения не являются таковыми, поэтому мы можем продолжать обсуждать, что из них следует делать.
Ира Бакстер
1
Я не уверен, что у нашего метода есть конкретное имя. Наши требования - это то, что я бы назвал гибридом между требованиями естественного языка и проектными документами высокого уровня. У нас обычно есть два раунда редактирования. Во-первых, мы документируем, что функция должна делать простым языком. Затем мы точно указываем, как это будет работать с точки зрения пользователя. Документ имеет две цели. Во-первых, мы хотим предоставить документ, который может быть рассмотрен нашей маркетинговой командой, чтобы убедиться, что мы отвечаем потребностям нашего бизнеса. Во-вторых, мы хотим предоставить документ, который может быть использован нашей командой QA для тестирования.
Пемдас
1
Наши проектные документы намного более формальны и подробны. Они всегда включают следующее: какой-то анализ вариантов использования, любое объяснение компромиссов или причин, по которым мы выбрали конкретный способ ведения дел, ссылки на другие конструкции, явные определения интерфейса, структуры данных ... и т. Д. У нас не обязательно есть явные комментарии относительно того, как конкретный код соответствует определенным требованиям. Я не знаю, считаю ли я это важным.
Пемдас
1
Я бы сказал, что наши документы на 95% актуальны. Несколько вещей тут и там просачиваются сквозь щели.
Пемдас
2

Я вижу две проблемы.

Во-первых, чертовски трудно поддерживать синхронизацию кода и документации. Если они разделены, они будут расходиться, и документация станет бесполезной. Программисты пытались использовать инструменты для их синхронизации (например, CASE-инструменты), но эти инструменты попали между программистами и их кодом, что принесло больше вреда, чем пользы. Одна из ключевых идей доменного дизайна (Evans, 2004) заключается в том, что хороший дизайн действительно сложен, поэтому, чтобы извлечь из него что-то, вы должны:

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

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

Те немногие математические инструменты, которые у нас есть, такие как формальные методы, очень громоздки.

Map-Reduction - хороший пример математики в программировании. Основная идея заключается в следующем: если у вас есть ассоциативная бинарная операция, вы можете очень легко распределить ее выполнение. Бинарная операция - это функция с двумя параметрами, ассоциативность подразумевает, что (a + b) + c = a + (b + c)

a1 + a2 + ... + a99 + b1 + b2 + ... + b99 + c1 + c2 + ... + c99

(a1 + a2 + ... + a99) + (b1 + b2 + ... + b99) + (c1 + c2 + ... + c99), где As, Bs и Cs могут быть добавлены в разных местах, их результаты собраны и подытожил в кратчайшие сроки.

Уменьшение карты - смехотворно простая идея. Это можно описать на одном листе бумаги. Если вы можете предположить, что читатель имеет твердое понимание концепции ассоциативности, если помещается на довольно маленьком листе бумаги. Теперь попытайтесь объяснить кому-то map-проводить без использования термина «ассоциативность» или косвенной ссылки на него. Попробуй.

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

Возможно, Haskell сможет это исправить со временем. Использование концепций из теории категорий для описания программ выглядит многообещающе для меня. Теория категорий настолько абстрактна, что даже математики мало ее используют, но, очевидно, категории, которые являются абстрактными до неузнаваемости, кажутся достаточно абстрактными для описания структуры программного обеспечения. Мы узнаем. Медленно.

Waquo
источник