Чи слід створювати діаграми класів до або після впровадження?

Я бачу це, якщо ви створюєте його, перш ніж отримати перевагу:

• Планування наперед
• Огляд проекту

але ти програєш:

• Час (виконуючи роботу, ви, ймовірно, в кінцевому підсумку повторюєте, коли пишете код)

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

Який з них відповідає призначенню діаграм класів, а який вигідніше?

Якщо їх створити раніше, вони будуть частиною етапу проектування.

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

До речі, ви не втрачаєте часу на розробку дизайну! Частина кодування буде швидшою. І краще.

Зрештою, ви думаєте, що робити дизайн хмарочоса чи мосту - це втрата часу, а не просто його будівництво?

Компроміс полягає в тому, щоб почати створювати деякий фіктивний код на етапі проектування (лише прототипи класів / функцій) і використовувати цей кодовий скелет для побудови діаграм класів.

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

У будь-якому випадку вони залишатимуться як частина документації. Ніхто не оновлюватиме їх, коли зміни будуть внесені до реалізації. Діаграми не матимуть на них дат, тому ви навіть не знаєте, до якої версії коду вони посилаються. Коли до проекту буде додано нову людину, ви дасте йому діаграми із записом "Ось деякі діаграми, які були створені в якийсь момент під час проектування чи впровадження. Ми не знаємо, наскільки вони сучасні".

Це частина дизайну, і тому її слід створити до впровадження. Це не означає, що вони не можуть бути доопрацьовані під час / після впровадження, щоб відобразити поточний стан реалізації.

Надання дизайну після впровадження - це те, що я б назвав «ковбойським кодуванням», і я впевнений, що ви можете процвітати на дикому дикому заході, але пам’ятайте, що ковбої зазвичай в той чи інший момент закінчуються мертвими.

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

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

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

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

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

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

Створення діаграми класів слід здійснювати під час та після, оскільки модель повинна бути інтерактивною з кодом та модифікаціями вимог. Для початку потрібно створити діаграму класів, щоб розпочати проект. Це допоможе візуалізувати на більш високому рівні абстракції ваші об'єкти. Ви зможете створити стабільну та інтелектуальну архітектуру програмного забезпечення. Тоді вам потрібно кодувати, і іноді ви помітите, що архітектура, яка, здається, добре знаходиться в UML, насправді неможливо в коді. Потім ви змінюєте код та архітектуру. Нарешті, ви оновлюєте свою модель за допомогою модифікації коду та генеруєте документацію.

У моєму останньому керівництві проектів за останній рік змінилися мої вимоги понад 50 разів. Це дуже боляче, і UML допомагає мені зберегти простежуваність змін і чому. UML повинен дозволяти з’єднання моделі та коду в будь-який час ітераційним способом (наприклад, від коду до моделі, від моделі до коду, від обох, від коду після рефакторингу тощо). Я використовую Omondo EclipseUML для Helios, і я дуже задоволений цей інструмент. Моєю улюбленою особливістю є злиття моделі, яка дозволяє мені в будь-який час оновити свою модель без втрати інформації про модель. Мені також подобаються особи, що моделюють безпосередньо на діаграмі класів та створюють базу даних, використовуючи стереотип та сплячий режим. Дійсно потужний і повний від об'єкта до бази даних !!

Перед тим : це допоможе змусити ваші думки впорядкувати та повідомити про свої наміри. Не вникайте тут у деталі.

Після : це автоматично генерується з коду як частини процесу збирання, очевидно (сподіваюся, ви не надто прив’язані до uml)

Обидва корисні, але раніше речі можна викинути, як тільки вони будуть реалізовані ... в цьому моменті це вже застаріло.

Завдяки Topcased я створюю свої діаграми класу під час проектування. Потім натискаю кнопку "Створити код" для створення полотна моєї реалізації. Потім я заповнюю заповнювачі з кодом.

Я буду голосувати за відповідь (С) Не турбуйтеся.

Вони в основному непотрібні. Особисто я ніколи не намагаюся дивитись на них, коли вони надаються.

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

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

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

З Ейфелем та пов'язаними з ними інструментами це лише різниця точок зору, які вказують на ті самі базові файли.