Як часто ви використовуєте Formal UML?

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

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

Ніколи.

Чорт, минуло років, як я востаннє створив будь-який UML. Лінійні діаграми на дошках та клаптиках паперу не враховуються.

Насправді ми лише видалили єдине запитання щодо UML з посібника, яким ми користуємось під час інтерв'ю, оскільки ніхто з нас насправді не хвилював відповіді.

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

Як не дивно, UML повинен бути гнучким.

У реальному світі це не повинно бути педантичною вправою робити це одним правильним способом. Йдеться про ефективне спілкування та документування системи / процесу / ідеї.

Щоб відповісти на ваше запитання, я з іншими. Я ніколи не використовував повноцінний офіційний UML.

Я дуже регулярно використовував UML близько чотирьох років для продукту, який генерував усі (більшість) скелетів коду від Rational Rose.

За останні п’ять років було створено більше «коробок і стріл», які в основному були винайдені на місці, і зазвичай їх вистачає для загального уявлення. За цей час формально виправте UML лише кілька разів.

Однак у мене був професор або два, які перешкоджали використанню суворої формальної UML якомога ближче до специфікації.

Запитайте свого професора, коли він востаннє використовував такий підхід у реальній системі. Серйозно.

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

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

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

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

В інший час вам доведеться використовувати щось інше замість / крім UML (фактичні математичні формальні моделі, такі як мережі Петрі, CSP або часова логіка.) Прикладом цього є системи в режимі реального часу, системи, де збої катастрофічні (медичні пристрої) або там, де ви зобов’язані за контрактом (наприклад, як у Європі, коли розробляєте транспортні системи.)

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

Якщо ви досить розумні, щоб використовувати випадкову неформальну модель таким чином, який є ефективним і доцільним, щоб виконати роботу, то так і нехай буде. Таким же чином, від вас очікується, що ви визнаєте, коли НЕ використовувати неформальний підхід та / або коли НЕ використовувати офіційний.

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

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

Мої висновки полягали в тому, що метафори та нотації UML запозичені, але мало дотримується строгості інструментів.

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

Звичайно застосовуються звичайні застереження академічних досліджень :)

Посилання на конспект паперу та саму папір (якщо у вас немає доступу до ACM) .

Крім цього, я настійно рекомендую "Agile моделювання" Амблера.

Ми використовуємо офіційний UML для генерації коду в сплячому ORM. Більшість інших речей - це неформальна або біла дошка. Для нас це важливо лише з генерацією коду, оскільки відсутність формальності порушить його.

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

Крім того, те, що ви використовуєте UML, не означає, що вам потрібно ставити крапки над кожним i і перетинати кожну t відповідно до стандарту. Це лише якщо ви хочете зробити якесь генерування / виконання автоматичного коду. Я не знаю нікого, хто це робив для більш ніж одного проекту.

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

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

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

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

Коли я читав про UML, я спробував це з усіх проблем, які я мав вирішити у своєму курсі C ++. На щастя, один із перших прикладів, які я спробував, - це описати пов'язаний список.
Не працювало.
Сказане, в поєднанні з хорошим процесом моделювання UML є корисним. Просто тому, що це для кращого чи гіршого стандарту.
Я хотів би побачити мову опису шаблону мета програмування. Я думаю, що це допоможе багато в розумінні того, що відбувається в <<<>>>

UML болісний, якщо ви також спробуєте розробку Model Driven. Я маю на увазі, що UML є дуже корисним графічним позначенням, а все інше марно. Я не витрачаю на моделювання, але використовую UML щодня для створення структури моїх проектів. Що я роблю, це швидко намалювати основну діаграму використання на рівні вимог, а потім негайно перейти на діаграми класів. Я додаю простежуваність вимог між діаграмами Usecase та класами. Діаграма мого класу також створює код, оскільки він синхронізований в реальному часі. Жоден тег у коді вся модель не зберігається у моделі UML, яка відображена у проекті Java.

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

Моделювання UML вимагає менше 10 хвилин на день, що робиться, коли мені потрібен час, щоб подумати, що мені потрібно розвивати і як.

UML - це чудовий, фантастичний і дуже корисний, але розвиток моделей - марний !!

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

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

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

На мою думку, Єдиний процес має багато достоїнств, але вся практика карбування візуальних артефактів, що б там не було мовою моделювання, трохи смішно. Документально доопрацьований документ, що містить серійний список, наприклад, який може бути створений за допомогою Word, Workflowy, Evernote, OpenOffice або назвати текстовий процесор, цілком здатний документувати те, що вимагає Уніфікований процес. Щось над цією простою джейню може бути легко опрацьовано декількома користувачами, керованими версіями, і якщо хтось обрав правильний інструмент для цього, команда могла б одночасно працювати над цим. Це набагато простіше зробити, ніж коли UML видався необхідним режимом об'єднання полчищ.