Pull to refresh

Comments 67

Проблема в том, что UML — это та же спецификация, только описанная графически, а не текстом.
И поэтому ее будет преследовать тот же бич всех спецификаций — по мере имплементации реальный код будет все больше и больше удаляться от спецификации, если постоянно их не синхронизировать. А так как на синхронизацию очень многие забивают, то получается, что UML для многих — это просто трата времени, так как в итоге все равно надо смотреть на код.


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

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

Автоматическая генерация кода по спецификации никогда не работает.


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

Согласен, автоматическая генерация кода будет еще не скоро, если будет вообще.
Чегой-то она «будет»? Она была, использовалась и была выброшена на помойку. Называлось Rational Rose и вообще RUP. Жуткое творение.

А по теме — UML ничем не лучше рисунтов на салфетках. Да, это некий стандарт. Да, его все понимают. Да, его иногда даже используют (sequence diagrams — программисты, data flow — архитекторы). Но как сказано было выше любая спецификация устаревает в тот момент, когда ее начинает читать программист. Поддерживать документацию? Ну если только вообще нечего больше делать :)

RUP общего с Rational Rose имеет только слово Rational.
Rose не умела генерировать алгоритмы.
Data flow нет в UML.

Роза генерировала код, но только зачем? Код и так является отличной документацией сам по себе.
Разобраться в любом коде намного сложнее чем в диаграмме.
RUP как раз и есть процесс Rational Software и воплощенный в Rose: «The Rational Unified Process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003.» WiKi.

Алгоритмы целиком она конечно не генерировала, но ниже классов и даже методов спускалась. Для того весь код был размечен коментириями страшного вида. Этим достизалась синхронизация диаграмм -> кода и обратно.

Data flow диаграмм нет, но activity diagram есть.
А можно ли наоборот? Генерировать диаграммы из кода, что бы диаграммы были в актуальном состоянии?
Да можно. И даже нужно, чтобы оперативно видеть структуру отдельно взятой части проекта.
К примеру, с этим вам может помочь IDE от JetBrains, там можно генерировать диаграммы. Ссылка

Жаль, что только классов… Хотя как другие делать я не представляю :)

Остальные диаграммы намного тяжелее с кодом соотнести
Автоматическая генерация кода по спецификации никогда не работает.

Ну почему не работает? Работает. Например для генерации кода в системах управления реального времени — автомобильных, авиационных, космических системах. И в системах цифровой обработки сигналов.


Там логика контроллера или преобразователя сигналов полностью описывается графически диаграммами состояний и сигналами и блоками, моделируется и проверяется вместе с объектом управления или генераторами сигналов и из нее генерируется Си или HDL код.


Модель — это и есть функциональная спецификация, а сам подход называется Model-Based-Design. Только UML там нет...

Там логика контроллера или преобразователя сигналов полностью описывается графически диаграммами состояний и сигналами и блоками

Тогда это графический язык программирования, а не спецификация


Только UML там нет...

И это не случайность.

Тогда это графический язык программирования, а не спецификация

Это именно функциональная спецификация. Она описывает, что должен делать контроллер словами системного дизайнера. О программировании он при этом не знает.
Сравните вот эту диаграмму состояний в Stateflow
image
С диаграммой состояний UML
image
Не видите знакомые элементы?


А вот вам диаграма состояний нагревателя в Stateflow.
image


Чем вам не UML? Разве не читается? А ведь из нее можно сгенерить вполне рабочий код.

Вот эти after(5, sec) и превращают схему в графическую программу. Тут нельзя написать after 5 sec или там since(sec, 5) — автор схемы должен разбираться в доступных ему командах.


О программировании он при этом не знает.

Это он так думает...

Вот эти after(5, sec) и превращают схему в графическую программу. Тут нельзя написать after 5 sec или там since(sec, 5) — автор схемы должен разбираться в доступных ему командах.

Это необходимый синтаксис для того, чтобы система правильно моделировала поведение диаграммы. Вы же хотите посмотреть как оно будет работать до того, как начнете программировать? Иначе, как я уже говорил, вообще смысл моделирования теряется — что толку от такой диаграммы, если ее нельзя прогнать через моделирование?

Смысла моделировать поведение программы и правда нет — программу можно запустить.


Вы же хотите посмотреть как оно будет работать до того, как начнете программировать?

Если я увижу как оно "будет" работать со всеми деталями — значит программа уже написана, и что я тут делаю?

Только UML там нет...

Вообще-то есть. Называется Action Semantics for UML.
Можно подойти с другой стороны. Генерировать UML из кода.
Так смысл как раз в обратном, т.е. вы делаете модель по коду, какой в этом смысл? Только если для документации… и то сомнительно это.
Для документации. Чтобы она не расходилась с реализацией. Что в этом сомнительного?
Такие «обратные» UML помогли бы разобраться новичку в проекте

Ужасная штука.
Проходили. Знаю.
Код получается громоздкий и плохо читаемый, любое внесение изменений в него (а без этого не обойтись) приводит к тому, что обратно из UML новую версию не сгенерить.
Мертворожденная идея фирмы Rational Rose.


Могла бы работает только в идеальном мире, в котором:


  • ТЗ проекта отлита в бериллиевой бронзе.
  • Структура классов и архитектура ПО так же отлита в бериллиевой бронзе.

В жизни — не работает.

Ну вообще это моделирование работы вашей программы. И этот этап должен быть обязательно. Иначе как вы докажете, что ваша программа будет работать, так как вы предполагаете. Это сродни, электронике. Вначале схема, расчет, моделирование, а потом уже паять элементы. В целом же к UML пришли не потому что это круто, а потому вообще-то для моделирования ПО используют математику (дискретную математику). Где весь ваш софт модулируется на уровне математических формул с доказательствами и это называется формальная спецификация. В принципе, можно использовать полностью аппарат дискретной математики и доказывать или опровергать, все вплоть до заявлений, что если Вася баскетболист, то он высокий. Но это не каждому дано, поэтому его немного упростили и сделали специальные языки типа Z, VDM. Но и это большинство программистов не устроило, так как не многие на таком уровне владеют математикой, поэтому перешли на полу-формальные спецификации, к коим относятся и графическое представление и UML…
Первично все таки UML, а потом код, а не наоборот. Т.е. не надо генерить UML из кода, это неправильно, а вот из UML в код можно. Но лучше, просто вначале делать изменения в UML, а потом переносить их в код… и встроить это в процесс.

Моделирование — это не всегда работы типы проектирования. Моделирование как документирование, описание того что уже имеется или сделано без лишних деталей, тоже используется. Банальный школьный глобус — модель земного шара, модель как описание, а не как проект :)

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

Предварительное проектирование никак от очень очень много итераций не спасает в условиях меняющихся требований. В какой-то момент времени проектные модели начинают отставать от кода, вернее код ответвляется от проектной модели, так её полностью и не имплементировав. А возможность генерировать UML означает возможность получить актуальную техническую документацию в любой момент.

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

Какая разница кидаться менять код сразу и методом проб и ошибок искать правильный вариант, или кинуться поменять модель, а потом по ней тупо сделать код… В код не все сразу смогут въехать, что там вообще происходит, а модель она проще, её понять могут многие, и если что могут дать дельные советы… и на этапе моделирования еще успеть серьезные огрехи в архитектуре поправить. А код по архитектуре можно написать быстро. Даже замеряли мы на примерно похожих проектах с разными подходами, если код писать без моделирования то очень быстрое начало, в пропорциях примерно так, через месяц уже можно отрапортовать, что все (а точнее код) готово на 90%, а потом 11 месяцев еще доводить до ума эти 10%. А с моделированием, через 2 месяц можно сказать, что модель на 90% готова (при этом, ни строчки кода ни написав), потом 2-3 месяца на реализацию модели и детальное моделирование и 2-3 месяца доводку модели с кодом, т.е примерно в 2 раза быстрее, а про качество вообще молчу.

Вы так говорите, как будто архитектуру нельзя описать кодом, а в графическую модель все сразу могут въехать. Кроме очень большой трудоемкости рисования диаграмм, самый большой их недостаток по опыту: мало кто их понимает хоть как-то (я — хоть как-то, без чтения спек UML не возьмусь реализовывать ни одну схему в статье, даже схему работы часов я не понимаю), а чаще бизнес даже не пытается их смотреть, принимая их за техническую документацию, которую непонятно зачем ему на утверждение приносят. Вот с BPMN они любят возиться, по своей инициативе их даже рисуют, а UML им просто неинтересна. Выходит UML нужен только автору, как инструмент фиксации своих идей, если графическую фиксацию он воспринимает лучше других. Мне вот текстовая ближе и субъективно, и по результатам многочисленных психологических тестов.


Может быть UML имеет смысл в организациях, где над проектом сначала работает архитектор, рисует схемы, отдаёт их программистам и с проекта уходит. А вот для себя, в качестве инструмента общения с бизнесом (что бизнесу показывать в конце спринта первые два месяца?) или в качестве рабочего инструмента команды, он, по-моему, избыточен


И на практике слабо понимаю как можно 2 месяца что-то моделировать, не имея возможности проверить как оно соответствует бизнес-требованиям.

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

Не соглашусь с этим: если код писали НЕ Вы — перечитывать кучу хитросплетений модулей и имен и зачем это все сделано и как работает — это явно не быстро. Зачастую ВЫСОКИЙ УРОВЕНЬ в виде документации UML или текстового описания коллегой в чате (что одно и тоже — ВЫСОКИЙ уровень ключевое) — будет эффективней для понимания хоть всей системы, хоть конкретного алгоритма (если по нему вам описали).

Для понимания нюансов — вроде как производительно у нас тут работает (где оптимизить, где итак ок), или какие модули с чем связаны вплоть до параметров методов и иерархий классов — разумеется будет накладно описывать в виде UML просто потому что это другой УРОВЕНЬ детализации, его конечно лучше в коде читать.

Ну вот реальные примеры UML мне всегда сложно читать. От кучи пересекающихся стрелок, где иногда даже пальцем водя по бумаге непонятно куда или откуда стрелка идёт до простого незамечания каких-то нюансов типа 1:1 связь или 0..1:0..1

Только вот про моделирование в статье аж всего два слова. Как и во всех описаниях работы с UML тоже. Для меня модель системы — это когда ты на вход подаешь информацию — а на выходе получаешь ее реакцию.
Например вот есть в UML диаграма состояний. ОК, как ее промоделировать? Как проверить, что все состояния правильные и переходы правильно отрабатываются? А иначе, я так тоже могу самолет от руки нарисовать и сказать, что это мое представление о нем в UML. А как это проверить?

Чисто логически, поэтому и называется, полуформальный. Т. Е., ты смотришь на модель, например диаграмму последовательности, преполагаешь, а что если другой поток будет обращаться… Ага надо добавить вызов лока… И так далее. Ее может посмотреть другой программист, проанализировать и сказать, что да работать будет… реализовывай…

*генерация UML из кода. В смысле, поддержка актуальной документации согласно проекту. Но, если проект около и больше 30 человек, это должен сидеть отдельный человек и заниматься только тем, что сличать UML из документации и полученную из реализации, после чего идти и разбираться, если где чего не так.
Зато потом из UML прекрасно пишется и дополняется документация.
Ну и отдельные косяки сразу бросаются в глаза.
Не буду утверждать, что ниже-написанное является правильным подходом, но в некотором приближении очень облегчает работу.
Допустим надо реализовать некое сложное, асинхронное взаимодействие.
1. Рисуем диаграмму последовательностей, основываясь на своих предположениях.
2. Реализовываем ее в лоб — последовательно сверху вниз
3. В процессе реализации понимаем, что вот этот этап надо бы совсем по другому реализовать, возможно даже с переделкой нескольких предыдущих
4. Возвращаемся к схеме(!) и дорабатываем необходимые места
5. Продолжаем разработку с самого «верхнего» измененного места
6. goto 3

Тут главное перебороть в себе укоренившееся представление, что «код первичен, а схемы вторичны» и сами с удивлением поймете, насколько проще и понятнее становится разработка.

Я признаю полезность UML, но единственный удобный инструмент для создания диаграмм классов, работающий под Linux, который я нашёл за разумные деньги это IDE от JetBrains. Пишешь код классов (скелет) и генерируешь диаграмму, если она требуется. Только мышкой потом перетащить остаётся, чтоб понятней было, и то стрелки кривые выходят.


Для остальных диаграмм и того нет. Поэтому диаграммы создаю в качестве отчёта, если єто входит в DoD задачи. Даже для задачи разработки архитектуры, когда написание кода не подразумевается, я его всё равно пишу. И если требуется не только диаграмма классов, то рисование остальных в более-менее презентабельном виде занимает обычно больше времени, чем собственно разработка. Иногда на порядки больше. Если заниматься этим чаще, то может быть чуть-чуть время уменьшится из-за того, что на каждый чих в спецификации лезть не надо будет. Но само рисование "мышкой и клавиатурой" никуда не денется.


Есть бесплатные или недорогие Linux или веб инструменты создания остальных диаграмм из текстового описания на каком-то языке (в идеале DSL, но yaml тоже пойдёт — что по коду их генерировать можно я не верю), без указания размеров и координат, с последующим ручным выравниванием для презентационніх целей?

К сожалению выравнивать нужно будет в любом случае. Сам часто пользуюсь автоматической генерацией от JetBrains, и даже она не всегда справляется на отлично. Я пользовался сторонними плагинами, в которых можно создавать диаграммы из короткого текстового описания, к примеру plantUml-integration. Лучше чем руками рисовать, но не так красиво.

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


За наводку на http://plantuml.com/ огромное спасибо!

Не знаю поможет это вам или нет.
Для Draw.io можно сделать описание диаграммы на html. Сначала вставляете ручками элемент, потом смотрите каким кодом он описывается (Дополнительно -> Редактировать диаграмму). Далее пишете свой парсер, который из вашего формата сделает описание на нужном html.
Мне помогает делать удобные и красивые схемы баз данных
Действительно, сам по себе UML — просто картинки, быстро теряющие актуальность по мере разработки. Более общий подход называется model driven devemopment и software factory, причем UML необязателен в качестве входного языка.
Пример реализации: GenieLamp
Как я понял в MDD основной упор делается на кодогенерацию и изначальное закладывание прочной архитектуры. Я прав?
В MDD упор на моделирование, но на выдающее на выходе работающий код (рутинный, прежде всего) и побочные продукты вроде документации). Сгенерированный код руками не меняется, только через модель, что обеспечивает постоянную актуальность. Более тонкую доработку каркаса можно программиривать руками в расширениях типа partial class или в обработчиках.
Есть также инструменты two-way, например ModelMaker: интегрирован в IDE, UML постоянно синхронизирован с кодом, менять программу можно с обоих сторон.

Основная проблема UML — расположение взаимосвязанных структур на плоскости.
С одной стороны, трудно охватить взглядом, с другой стороны связи накладываются друг на друга и перепутываются.
Судя по детективным фильмам, наиболее всего они помогают при анализе криминальных ситуаций.
PS Я не противник UML, но все же код писать и читать легче

Можно декомпозировать до нужного уровня детализации. Или использовать более подходящий тип диаграмм.

Диаграммы классов, в основном, бесполезны. Дело в том, что во многих языках программирования есть свои особенности, которые в UML не предусмотрены, и свои традиции реализации тех или иных паттернов. И при составлении диаграммы классов для них приходится сначала декомпозировать специфичные для языка вещи на элементарные сущности UML — а потом, при чтении диаграммы, мысленно собирать их обратно.


Скажем, в тех же C++ или Rust широко используется статический полиморфизм — а значит, вместо интерфейсов или базовый классов надо как-то показывать на диаграмме концепты и протоколы. Их еще и в языке нет — но в спецификации они должны уже быть...


Или взять в том же C++ лямбды. Формально это аж целый класс с одним методом, к тому же наследующий std::function<...>. Но в коде лямбда — всего лишь функция с квадратными скобками вместо имени...


То же самое касается и диаграмм деятельности: в коде у нас есть циклы, а на диаграммах деятельности приходится делать их через аналог goto.


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

Пытаться описать диаграммами специфичные для языка вещи не стоит. UML, в первую очередь, нужен для получения возможности посмотреть на систему в целом.

А диаграмма деятельности с «дорожками» и «циклами» — это диаграмма последовательности. Посмотрите в конец статьи planerka.info/item/diagrammy-posledovatelnosti

Нее, это разные вещи. Диаграмма последовательности показывает лишь один из вариантов развития событий, а диаграмма деятельности — сам алгоритм.


На диаграмме последовательности не бывает ветвлений, зато на ней хорошо видны фоновые задачи.

Они обе решают схожие задачи.
В диаграмме последовательности, посмотрите оператор «alt».
И диаграмма деятельности тоже поддерживает параллельные процессы.

По вашей ссылке:


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

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

Что же до поддержки диаграммами деятельности параллельных процессов — то там не видна их относительная продолжительность.

Согласен, у всех диаграмм есть преимущества и недостатки.

Скорее у них просто есть область применения, где они эффективно доносят информацию

Зачастую на практике важны имено конкретные варианты развития (они же — тестовые варианты). И показать на диаграмме что и за чем следует, в варианте 1 (а на другой диаграмме — вар 2) — вполне адекватное применение. Но да это не все случаи использования UML.

Просто конкретная диаграмма, как уже высказались, имеет смысл для того, чтобы показать то или иное — общий алгоритм (одной подсистемы, или высокоуровневой системы — разные случаи) или может состояние системы в нужный момент (со всеми объектами, или срез из нужного множества объектов)

Каким образом сказанное вами опровергает возможность добавить "дорожки" на диаграмму деятельности и НЕ получить при этом диаграмму последовательности?

И что я тут по вашему опровергал? Я говорю лишь то что говорю — а именно — если вам нужны конкретные тестовые варианты (а не целый алгоритм) — вы делаете на каждый тест вариант (основной, хоть на один — если он только важен) — Диаграмму последовательности. Это ее нормальное применение. Да это разные диаграммы. И «дорожки» обычно нужны чтобы показать что происходит на каждой стороне, т.е что делает клиент, что сервер, что человек (3 сущности например).

Если вам нужен алгоритм, во всех его проявлениях, т.е не один тест вариант, нужно юзать Диаграмму деятельности.

Есть помоему комбинированная, где есть и дорожки, и полный алгоритм, но это 3я (точно не 1я и не 2я).

p.s. извиняюсь если это выглядело как опровержение, или если тут так принято, писать коменты только ради опровержений. Я просто уточняю — что имею в своем опыте.

И в моей практике «Зачастую на практике важны имено конкретные варианты развития» это значит что «зачастую», а другую диаграмму в принципе и не юзал почти никогда, за не надобностью, но смысл в ней есть конечно, просто обычно — нужны конкретные варианты, и уже их них можно составить прямо сразу Код, минуя диаграмму деятельности, потому что каждый из тест вариантов — можно проверять прям по нужной диаграмме Последовательности.
И при составлении диаграммы классов для них приходится сначала декомпозировать специфичные для языка вещи на элементарные сущности UML — а потом, при чтении диаграммы, мысленно собирать их обратно.

То что вы конвертируете какието сущности из UML напрямую в язык-прогр, или наоборот из языка-прогр в UML — только подтверждает то, что вы используете ОДИНАКОВЫЙ УРОВЕНЬ и для UML и для языка-прогр, что не имеет никакого смысла на практике. Имеет смысл РАЗНЫЙ УРОВЕНЬ, например это planerka.info/item/diagrammy-posledovatelnosti написанное человеческим языком и там видно на прилично-высоком-уровне что делается каждый из модулей (или даже людей).

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

Не скажу за всех, но имхо — диаграммы классов — это уже очень-низкий-уровень, т.е делать их, а потом еще и писать код — дублирование работы. Исключением может быть диаграммы классов, составленные для обсуждения\документации подхода, и включающие только малое число классов и методов, которые явно не один-в-один будут перенесены на код. Т.е те диаграммы классов, что для обучения паттернам проектирования — они не подходят имхо, для нормального проектирования, потому что низкий уровень. Пример конкретный думаю вы сами сможете найти для не-очень-подробной-высокоуровневой-диаграммы-классов. Однако имхо и без них вообще можно обойтись.

Т.е использовать диаграммы: Последовательности, Прецедентов, state-machine — самые распространенные, и с их помощью можно именно высокий уровень задачи описать, и иногда детали реализации (но не скатиться в очень детальность).

Хотя та же state-machine (состояний) может быть применена как для высокого уровня, например юзер в состоянии = меню, кликает «в бой» и условно если есть соперники — сервер его помещает в бой сразу, или если нет соперников — ставит в очередь ожидания, и потом когда начнется состояние = бой, он может проиграть или выиграть или ливнуть из игры.
Но может быть и низкий уровень вроде описания работы TCP с его syn\ack и состояниями — что обычно редко когда нужно, но всетаки если и нужно — это низкий или средний уровень, думайте сами — нужны ли они вам, мне — обычно нет.

Т.е разница ключевая тут — сколько еще уровней-ПОД находится, и сколько кода надо написать… если много кода еще предстоит написать (т.е скрыто, за пределами диаграммы) — имхо нормальная диаграмма, и предназначенная для overview\обучения\обсуждения, а вот если кучу подробностей — так это почти уровень кода, и дублирование работы.

Если комментировать ваш первый тезис
Диаграммы классов, в основном, бесполезны.

Тогда я согласен по большей части

Проблема с UML в том, что надо, чтобы его понимал еще кто-то, кроме меня. :)


На практике получается так: BDD, DDD и современные IDE вполне решают проблему "разобраться с архитектурой", а при обсуждении — псевдокод и квадратики со стрелочками в свободной форме, отдаленно напоминающие UML.

Ну да согласен, не важно, в какой форме, главное, чтобы людям понятно было… Просто UML как бы стандартизировал подход для большинства, чтобы большинство на одном языке говорили, а так, можно как тут говорили, хоть на салфетке рисовать стрелочки и круглишки, главное, чтобы не потерялось :)
Ну а еще в момент анализа (хоть составлении новой функции в существующую систему, которая пойдет и повлияет на другие; хоть в момент составления новой системы) вам самим он помогает, это не мало, это не «всего лишь только мне понятно» это «без него я бы тут запутался если бы код писал»

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

А если это на один раз — доносите человеческим языком, задавайте вопросы, обсуждайте — как угодно, но это не смысл и не use-case для UML, и это не его минус.

Те же слова, написанные русскими буквами, зачастую не понятны людям, они задают уточняющие вопросы, чтото переспрашивают… это же не минус русского языка правда?
UML
1. Способ графического отображения идей для принятия решений.
2. Способ графической примитивной фиксации решений, которая устаревает.
У любой документации (да и вообще любого артефакта) должен быть ответ:
— кому это нужно
— и что он с этим делает

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

Аналогично с документация для ИТ-систем. Если ею пользуются несколько команд на регулярной основе, то поддерживать в актуальном состоянии ее становится выгодно. UML — всего лишь способ описания, который понятен большинству. И команда с удовольствием обновляет документацию, потому что для нее очевидна выгода актуальной документации.
Далее мое имхо. Смысл в UML или любом другом языке моделирования (хоть блок-схемы, хоть текстовое описание) — именно в разном УРОВНЕ представления.

Например: сначала архитектор создает скелет — условно диаграмму последовательностей из клиента-сервера-юзера и там отображаются кто кому какие ВЫСОКО-УРОВНЕВЫЕ команды посылает, в этом и смысл, не нужно все детали отображать. А если нет деталей — не возможна кодо-генерация, ну можно условно шаблон сгенерировать из классов и пары методов, а потом всеравно начинку (код кучи if-ов и методов и параметров).

Другой пример: рисуется диаграмма state-machine — она СРЕДНЕ-УРОВНЕВАЯ — и предназначена для решения конкретной задачи, условно там есть Init (где начало) и переходу при кликах юзера в UI, в зависимости от условия (if просто другим языком) делается переход в состояние, в котором и UI будет другой и команды перехода из-в будут другими, т.е конкретный алгоритм можно сказать. Но это все еще НЕ-КОД, т.е конкретные детали всеравно придется кодить (вызывать конкретные методы\функции, передавать нужные параметры, рисовать чтото в UI, отслеживать события из UI от юзера и т.п).

Смысл этих уровней — есть. Но он должен быть осмысленным.

Т.е не так что «сделаем диаграммы на все что у нас в проекте будет — а код сгенерируем» — не сработает т.к. вы диаграммами высокого уровня хотите сгенерить код низкого уровня? это же не верно… просто потому что вам в момент проектирования ВЫСОКОГО-уровня неважно(!) что на низком будет, пусть там хоть Set\List\Dict будет, хоть цикл с полным перебором, и какой там UI и какие события — не важно.

В обратную сторону «напишем код — тулза нам сгенерит документацию на UML» частично может работать, но это для ОБУЧЕНИЯ, т.е входа новых лбюдей в этот проект, или написания книжек по паттернам проектирования (это тоже важно).

Зачастую нужен баланс и понимание того что мы сделаем ВЫСОКИЙ уровень системы клиент-серв (например, если у нас эта задача), сделаем СРЕДНИЙ уровень для ПОДСИСТЕМЫ UI с диаграммой состояний, сделаем еще СРЕДНИЙ уровень для ПОДСИСТЕМЫ рендернга 3D графиик на клиенте, и потом еще напишем кучу НИЗКО-уровневой реализации во многих подсистемах (кучу if, имен методов и параметров, их типов, кучу enum и т.п — все это описывать в ВЫСОКО-уровеном UML\диаграмме зачастую нет смысла, если только они не ключевые в понимании системы).

Где-то (уже не помню) читал о том что мышление наше МНОГО-УРОВНЕВОЕ, но вот тулз для поддержки этого мышления в программировании — пока нет, полноценных по крайней мере, т.е то что есть в виде отдельных кодо-генераторов — уже описал — слабо помогает.

Идеально это если бы были и work-flow (как мы делаем, инструкции для программистов по проектированию) и чем — какими тулзами \ генераторами \ IDE, и как все это в общую систему свести.
Были такие попытки в духе RUP… на сколко знаю — не идеально.

ДУМАТЬ УРОВНЯМИ вам никто не мешает. Так и нужно думать. Т.е. создавать (хоть в голове и потом забыть \ хоть текстом и потом выкинуть, ну можно и задокументировать) какойто один высокий уровень, проектировать постепенно и волзвратно средние уровни, и чтобы все это не устаревало — всеравно как-то нужно поддерживать ЗНАНИЯ. Т.е ключевое тут — НЕ-КОД, НЕ-UML, а ЗНАНИЯ! Т.е программист, когда он решает даже потом вернуться к задаче — не код должен дублировать в виде документации, или документацию пере-генерировать в код и потом фиксить это, ему ЛЮБЫМ СПОСОБОМ надо поддерживать РАЗНЫЕ УРОВНИ ЗНАНИЙ. Пока способов поддержки УРОВНЕЙ — мало, и все не очень… т.е ктото будет лениться писать документацию (даже комменты в коде — помогают, если они на ДРУГОМ УРОВНЕ), потом лениться ее править, и они хотят чтобы чтото за них это сделало… нет такой тулзы, чтобы вам сделать много УРОВНЕЙ — по вашему желанию. Поэтому зачастую программисты поддерживают ТОЛЬКО КОД. Ну чтобы единый источник был. Они думают что это ИДЕАЛ, чтоб не дублировать документацию. Но смысл всеравно остается — эти УРОВНИ они должны гдето брать — когда надо пофиксить чтото, добавить функционал, обучить когото — вспомнинать приходиться из головы, или придумывать\ проектировать заного.
Sign up to leave a comment.

Articles