Чому ми не можемо захопити дизайн програмного забезпечення більш ефективно? [зачинено]

Як інженери, ми всі "проектуємо" артефакти (будівлі, програми, схеми, молекули ...). Це діяльність (design-the-verb), яка дає певний результат (design-the-noun).

Я думаю, що ми всі згодні з тим, що іменник design - це інша сутність, ніж сам артефакт.

Ключовою діяльністю в бізнесі програмного забезпечення (дійсно, у будь-якому бізнесі, в якому необхідно покращити отриманий артефакт продукту) є розуміння "дизайну (іменника)". Однак ми, як спільнота, здаємося в повній мірі повними невдачами при його записі, про що свідчить кількість зусиль, які люди докладають до перекриття фактів про свою кодову базу. Попросіть когось показати вам дизайн їх коду і побачити, що ви отримаєте.

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

• Явна специфікація того, що програмне забезпечення повинно робити та наскільки добре воно працює
• Явна версія коду (ця частина проста, у кожного є)
• Пояснення, як кожна частина коду служить для досягнення специфікації (наприклад, співвідношення між фрагментами специфікації та фрагментами коду)
• Обгрунтування , чому цей код так , як це (наприклад, чому конкретний вибір , а не інший)

Що НЕ є дизайном, це особливий погляд на код. Наприклад [не вибирати конкретно] Діаграми UML не є конструкціями. Скоріше, це властивості, які ви можете отримати з коду, або, можливо, властивості, які ви хочете отримати з коду. Але, як правило, ви не можете отримати код з UML.

Чому після 50+ років створення програмного забезпечення, чому ми не маємо регулярних способів висловити це? (Не соромтеся суперечити мені явними прикладами!)

Навіть якщо ми це робимо, більша частина спільноти здається настільки зосередженою на отриманні "коду", що іменник дизайну все одно втрачається. (ІМХО, поки дизайн не стане метою інженерії, з артефактом, вилученим з дизайну, ми не збираємося обійти це питання).

Що ви бачили як засоби для запису конструкцій (у тому сенсі, як я це описав)? Явні посилання на документи будуть добре. Чому, на вашу думку, конкретні та загальні засоби не досягли успіху? Як ми можемо це змінити?

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

EDIT 2011/1/3: Один рядок відповідей натякає на те, що "документація" (імовірно текстова, зокрема неформальна) може бути адекватною. Я думаю, я повинен уточнити, що я не вірю в це. Інструменти CASE з'явилися на сцені, починаючи з 80-х, але ранні інструменти здебільшого просто захоплювали пікселі для діаграм всього, що ви намалювали; Хоча інструменти, мабуть, були комерційно успішними, вони справді не були дуже корисними. Ключовим розумінням було те, що якщо додаткові "дизайнерські" артефакти формально не інтерпретуються, ви не зможете отримати будь-яку серйозну допомогу інструменту. Вважаю, те саме розуміння стосується будь-якої довготривалої корисної форми захоплення дизайну: якщо вона не має формальної структури, вона не матиме реального використання. Текстові документи майже не піддаються цьому тестуванню.

Я думаю, що є кілька причин, чому ми все ще не добрі в цьому.

1. Люди тривалий час, хоча програмне забезпечення було як будинки, і використовували процеси та ідеї з будівництва. "Архітектор програмного забезпечення" - це назва, яку хотіли всі програмісти. За останні десять років архітектор програмного забезпечення майже вимер. Ідея процесів водоспаду, де спочатку у вас є архітектор, який говорить, як програмне забезпечення повинно працювати і виглядати, а потім змушуйте людей робити діаграми того, як воно має бути побудовано, і нарешті, мавпа з кодом реалізує ці приємні діаграми робочих потоків / UML-діаграм для специфікації. зараз широко висміюється. Тож насправді вся індустрія йшла неправильним шляхом протягом 40 років.

2. Інструменти, які ми використовуємо, постійно змінюються та вдосконалюються. Програмування - це логічна загадка, і ми придумуємо кращі ідеї та прийоми, щоб абстрагувати цю головоломку та зробити її зрозумілою. Те, як ми моделюємо це, має розвиватися з однаковою швидкістю, але воно відстає. Вдосконалені прийоми абстрагування головоломки програмування також означають, що ми можемо збільшити складність. І так ми робимо. Програмування завжди лежить на межі складності, яку ми, як програмісти, можемо впоратися.

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

4. Тому; Якщо у вас є успішна і точна модель програмного забезпечення, ця модель буде еквівалентною програмній. Що нібито робить цілі зусилля безглуздими, що, в свою чергу, підтверджує пункт 1 вище: Моделювання програмного забезпечення набагато менш корисне, ніж вважалося раніше. Натомість краще витягнути дані про програмне забезпечення з коду. Створення моделі UML з вигляду коду насправді набагато просвітніше, ніж створення моделі UML та спроби впровадити цю теоретичну модель.

Можливо, вам буде цікаво переглянути літературу про відстеження програмного забезпечення. Ні в якому конкретному порядку:

• CUBRANIC, D., MURPHY, GC, SINGER, J., BOOTH KELLOGG, S. Hipikat: пам'ять проекту для розробки програмного забезпечення. Операції з інженерії програмного забезпечення 31, 6 (2005), 446–65.
• TANG, A., BABAR, MA, GORTON, I. and HAN, J. Огляд використання та документації обґрунтування дизайну архітектури. У програмі 5-ї робочої конференції IEEE / IFIP з архітектури програмного забезпечення (2005).
• RAMESH, B., POWERS, T., STUBBS, C. та EDWARDS, M. Простеження вимог щодо впровадження вимог: Тематичне дослідження. У Proc of Int'l Symp on Requirements Engineering (Йорк, 1995).
• ХОРНЕР, Дж., АТУУД, МЕ Обгрунтування проекту: обгрунтування та бар'єри. У програмі 4-ї Північної конференції про взаємодію людини та комп'ютера: Зміна ролей (Осло, Норвегія, 2006).
• CLELAND-HUANG, J., SETTIMI, R., ROMANOVA, E., BERENBACH, B., and CLARK, S. Найкращі практики автоматизованого відстеження. Комп'ютер 40, 6 (червень 2007 р.), 27–35.
• ASUNCION, H., FRANÇOIS, F., AND TAYLOR, RN Інструмент відстеження промислового програмного забезпечення, що відкладається до кінця. У програмі 6-ї спільної зустрічі європейського програмного забезпечення Eng Conf та ACM SIGSOFT Int'l Symp on the Foundation of Software Engineering (ESEC / FSE) (Дубровник, 2007).

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

Окремо зауваживши, що моя власна робота над Arcum була засобом для програмістів висловити IDE використання перехресних дизайнерських ідіом. Після вираження програмісти можуть потім перетворити свій вихідний код для використання альтернативних реалізацій:

• Макнейл Шонл, Вільям Г. Грісволд та Сорін Лернер. Поза межами рефакторингу: рамки для модульного забезпечення ідей перехресного дизайну . У матеріалах 6-ї спільної зустрічі Європейської конференції з програмного забезпечення та Симпозіуму ACM SIGSOFT з основ інженерії програмного забезпечення (ESEC-FSE '07; 3-7 вересня 2007 р.). 175-184.

До речі, Arcum також пов’язаний з вашою роботою DMS.

UML - це програма, яка планується до будівлі, на мій погляд. Плани самі по собі не є дизайном, звичайно, вам потрібні специфікації матеріалів (використовувані інструменти з кодом), загальний вигляд будівлі (деяке схематичне зображення всього програмного забезпечення, включаючи конструкції графічного інтерфейсу), як висаджується будівля в оточенні (чітка схема того, як програмне забезпечення взаємодіє з іншими / посаджено в ОС), як воно відповідає клімату та ґрунту (взаємодія з апаратними засобами), ... Багато книг з дизайну намагаються визначити це, але як з тим багато в науці, кожен учений має трохи свого визначення.

Тепер я також не згоден з вашим зауваженням, що ви не можете отримати код з UML. Ви можете, якщо у вас є зазначена додаткова інформація. Але справжній код вже не дизайн, це артефакт. Ви також не можете витягти справжні камені та бетон із плану, але вам потрібен план розмістити справжні камені та бетон у правильній формі та в потрібному місці.

У цьому світлі я знайшов цікаву наступну статтю (я зустрічав її в іншому контексті, коли шукав графічне програмне забезпечення, але, тим не менше ...). Графічний підхід для опису дизайну мав сенс для мене, хоча, на мою думку, це лише частина дизайну. Цікавим є те, що такий підхід дає основу для розуміння та рефакторної конструкції (на відміну від рефакторного програмного забезпечення), як зазначено в наступних документах:

• Вермелінгер і Фіадейро

• Цанталіс та ін

Існує маса інших підходів для опису (частини) дизайну, як структурований дизайн (графіки HIPO) або інтегрований дизайн програми , шаблони дизайну , ...

Тим не менш, доки немає галузевого стандартного набору, навряд чи знайдеться "звичайний" спосіб виразити це. Навіть після 50+ років. І будьте чесними, якби ваша компанія знайшла хороший спосіб висловити дизайн, ви поділилися б цим зі світом?

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

Кожна людина в моїй команді має ступінь інженера ... переважно EE або CE. Інженерія навчає вас проектувати як частину навчальної програми.

Я думаю, що існує маса так званих програмних інженерів, які походять з CS-середовища. Дизайн програмного забезпечення не є невід'ємною частиною більшості програм CS. Я не кажу, що всі спеціалісти CS погані в дизайні, але я б став до того, що більшість не має офіційної освіти, яка б цьому їх навчала. Я думаю, що багато людей припускають, що якщо ти можеш запрограмувати, то можна розробити програмне забезпечення, що не відповідає дійсності. Зважаючи на те, що багато програмістів не мають інженерного досвіду, це не дуже дивно, що у багатьох програмних проектах немає команди, яка добре займається дизайном.

Я бачу дві проблеми.

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

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

Інша велика проблема в тому, як ми робимо дизайн, полягає в тому, що наші методи проектування недостатньо математичні. Протікаючі абстракції не дають змоги робити з них ґрунтовні висновки, а світ суворо застосованої логіки та чіткої істини називається математикою, якої програмісти здебільшого ухиляються.

Кілька математичних інструментів, які ми маємо, такі як формальні методи, дуже непрості.

Зниження карт - хороший приклад математики в програмуванні. Основна ідея така: Коли у вас є асоціативна, бінарна операція, ви можете легко розподілити її виконання. Двійкова операція - це функція з двома параметрами, асоціативність означає, що (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 можна тривіально додавати в різних місцях, їх результати збираються і підсумували за короткий час.

Скорочення карт - смішно проста ідея. Це можна описати на одному аркуші паперу. Якщо ви можете припустити, що читач чітко розуміє поняття асоціативності, якщо він вміщує зовсім невеликий аркуш паперу. Тепер спробуйте пояснити зменшення карти до когось, не використовуючи термін асоціативність або посилаючись на нього опосередковано. Я смію тебе.

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

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