Який стандарт моделювання сучасних додатків до розробки?

Я приймаю свою першу заявку на рівні підприємства, і я хочу, щоб моя команда змоделювала всю програму ASP.NET MVC C #, перш ніж ми навіть використаємо один рядок коду.

ОНОВЛЕННЯ: Це не було метою філософської дискусії про те, коли потрібно документувати / моделювати додаток. Будь ласка, надайте відповіді лише на те, як "як" документувати / моделювати.

Правда полягає в тому, що я завжди скупився в цьому відділі, і ніколи ще ніколи не моделював програму. Який стандартний спосіб це зробити? Який тип діаграм слід використовувати та як виглядатиме документація? Посилання на зразкові діаграми та документацію високо оцінені.

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

Спасибі заздалегідь!

Заключна заява

Я не здогадувався, що це така клейка тема. Дякую всім вам, що могли відмовитися від очевидних суперечок та дати корисні відповіді. Цікаво було сказати цікаву дискусію :)

Ще одне корисне посилання, яке я виявив: /programming/61487/do-you-use-uml-in-agile-development-practices/61519#61519

сучасний сучасний консенсус

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

З іншого боку, між тими "спритними" людьми, які говорять "не робіть офіційних моделей, краще пишіть робочий код", і тими "BDUF" (великий фронт) люди, які мислять інструменти, як " MDA "(модель, керована архітектурою) - це рішення.

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

Я хочу, щоб моя команда змоделювала всю програму ASP.NET MVC C #, перш ніж ми навіть використаємо один рядок коду

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

Намагаючись розробити весь додаток наперед, перед будь-яким кодом (у всіх, крім найпростіших програм), як правило, безглуздо.

Ви справді вірите, що можете заздалегідь детально викласти кожен клас, метод та структуру даних?

Я просто хочу знати хороші рішення для моделювання.

Що стосується власне інструментів для виготовлення моделей, то я спробував декілька і завжди опинився в Microsoft Visio.

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

EDIT: Власне, я повинен сказати, що більша частина мого моделювання робиться на блокноті, який сидить на моєму столі. Оскільки я мало моделюю, намагаюся тримати його легким та чітким. Складання схеми ручкою та папером для мене набагато ефективніше, ніж використання програмного забезпечення.

Ви можете виявити власноруч написані діаграми, корисні для формування ваших ідей, перш ніж викладати їх у програмному забезпеченні для побудови діаграм.

Який тип діаграм слід використовувати та як виглядатиме документація?

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

Діаграми UML - це гарне місце для початку. Існує багато простих способів зробити це за допомогою безкоштовного або платного програмного забезпечення. Одним з простих прикладів інструменту для створення UML є щось на кшталт креслення документів Google, більш вдосконаленими пакетами будуть Visio або OmniGraffle.

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

Як @Brett запропонував, діаграми UML найкращі. З UML корисно мати діаграми класів та діаграми робочих потоків. Ці два покриють більшість дизайнерських потреб.

За допомогою діаграми класів ви можете моделювати членів кожного об'єкта, рівень їх безпеки тощо.

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

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

Я зазвичай створюю декілька контурних зображень у Visio, часто використовуючи будівельні блоки "блок-схеми", щоб візуалізувати, що я маю на увазі. Використання UML часто відчувається формалізованим та запрошує надто багато деталей. На кресленнях Visio показані основні складові програми програми та тип функціональності. Якщо ви використовуєте рамку MVC, то в основному це робиться лише взяттям зразка з Інтернету та його копіюванням.

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

• Використовуйте діаграму випадку (UML)
• План-схема або плавальна смуга UML (дуже високий рівень)
• Огляд архітектурних компонентів

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