Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Разработка информационных систем |
![]() ![]() |
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7 8 вперед Ctrl→ все |
Charles Weyland Member Откуда: Feorina "Fury" 161 Сообщений: 4303 |
Смотрю на все академические примеры использования UML и создаётся такое ощущение, будто они для программ в 1 мегабайт годятся. Смотрю на стройную диаграмму классов. У меня каждый класс имеет по несколько десятков методов (есть, конечно, маленькие, но есть и до 50). И классов реально куча. Не могу понять практический смысл описания подобным образом промышленных приложений. Или, предположим, ведётся разработка программы Excel. Необходимо создать Use-Case диаграмму. Не понимаю, что на ней отображать. Могу компактно перечислить возможности Excel. И мне видится это наглядным. Могу расписать каждую подробнее, если потребуется. Но раздувать из каждой строки громоздкие рисунки, плюс, непонятно, что на них рисовать, и плюс вариантов использования слишком дохрена. |
14 апр 19, 23:35 [21861807] Ответить | Цитировать Сообщить модератору |
hVostt Member Откуда: Сообщений: 16276 |
Charles Weyland, UML плохо подходит для моделирования реального программного кода. Разве что академические алгоритмы, или паттерны. Максимум, это архитектура без деталей реализации. И вообще, UML неудобен. |
15 апр 19, 02:10 [21861838] Ответить | Цитировать Сообщить модератору |
mad_nazgul Member Откуда: Сообщений: 4972 |
Charles Weyland, Поэтому UML в лучшем случае используется манагерами для презентаций заказчику. По идее в нулевых были попытки создать кодогенераторы на основе UML, но как-то "не взлетело" |
15 апр 19, 10:56 [21862111] Ответить | Цитировать Сообщить модератору |
МодальноеОкно Member Откуда: Сообщений: 2654 |
смысл в
|
||||
15 апр 19, 11:19 [21862152] Ответить | Цитировать Сообщить модератору |
МодальноеОкно Member Откуда: Сообщений: 2654 |
манагеры кроме use case с человечками вообще ничего не воспринимают |
||
15 апр 19, 11:20 [21862155] Ответить | Цитировать Сообщить модератору |
alex55555 Member Откуда: Сообщений: 2128 |
Когда придётся это всё кодить, то от раздувания никуда не денешься. Поэтому, хотя бы иногда, надо иметь карту боя. |
||
15 апр 19, 12:24 [21862282] Ответить | Цитировать Сообщить модератору |
hVostt Member Откуда: Сообщений: 16276 |
по большему счёту это тоже им не нужно :) |
||
15 апр 19, 19:33 [21862955] Ответить | Цитировать Сообщить модератору |
ViPRos Member Откуда: Сообщений: 9659 |
есть даже интерпретаторы |
||
15 апр 19, 20:07 [21862967] Ответить | Цитировать Сообщить модератору |
hVostt Member Откуда: Сообщений: 16276 |
ViPRos, https://yuml.me/diagram/scruffy/class/draw а можно не рисовать мышкой ) |
15 апр 19, 21:25 [21863017] Ответить | Цитировать Сообщить модератору |
betelgeizex Member Откуда: Сообщений: 87 |
PlantUML же! Лет N-цать как :) P.S. Не дай бох когда еще столкнуться с энтой красотой |
||
15 апр 19, 22:56 [21863072] Ответить | Цитировать Сообщить модератору |
Relic Hunter Member Откуда: AB Сообщений: 7099 |
Унас был УМЛ и начале нулевых. Когда консультант превисил 600+ страниц Use-Case его уволили (хотя он утверждал это только начало ![]() |
15 апр 19, 23:07 [21863074] Ответить | Цитировать Сообщить модератору |
Bsplesk Member Откуда: Сообщений: 139 |
Relic Hunter, Забыли дополнить, потом уволили всех разработчиков и закрыли/обанкротили фирму - т.к. что наделали разработчики осталось великой тайной - зачем оно вообще бизнесу и как это поддерживать/дорабатывать после ухода "аксакалов". Без USE CASE в первую очередь выгодно разработчикам - т.к. они становятся "незаменимыми", от части это решает "микросервисная ахитертура" - когда в случае чего просто выкидывают "поделие" без особых затрат заменяют другим не затрагивая остальные системы. USE CASE - по факту основа любого ТЗ (и предварительно сбора требований) если вы делаете что-то для бизнеса. Возмём для примера: https://habr.com/en/company/yandex/blog/442762/ - интересны в первую очередь "комменты". И смотрим, как при появлении 100/500 вопросов автор приходит сам того не осознавая к необходимости выделения "Кейсов/Сценариев использования". Ведь можно "не потом", а сразу - описать возможные кейсы (да возможно не все будет определено на начальном этапе - на этом кстати базируется оценка). И вот тут будет очень кстати UML activity/sequence. Чтобы была возможность у "предлагающих" "решения" - прогнать его по "кейсам".
|
||
16 апр 19, 09:56 [21863303] Ответить | Цитировать Сообщить модератору |
mad_nazgul Member Откуда: Сообщений: 4972 |
Bsplesk, Минутка КО Разработчики пишут код, в соответствии со спецификациями (ТЗ). Кто будет писать/документировать эти спецификации (ТЗ) это уже вопрос организации. Спецификации (ТЗ) должны быть написаны так, чтобы они были понятны как разработчикам, так и заказчикам (бизнесу). Главное здесь "ПОНЯТНЫЙ". Т.к. программист не понимает что ему говорит заказчик/бизнес пример. Хотя если подумать А теперь вопрос - кому понятен UML? Понятен он заказчику (бизнесу) - нет. Т.к. для "чтения" UML нужно учиться, а заказчику (бизнесу) это не надо. Понятен они программисту? Тоже - нет! Опять же из-за того, что надо учить новый ЯП! А потом переводить этот ЯП в другой "нативный" ЯП. Т.е. имеем некоторый птичий язык, который понятен только тем кто его знает и который не решает никаких проблем. :-) |
17 апр 19, 08:41 [21864400] Ответить | Цитировать Сообщить модератору |
МодальноеОкно Member Откуда: Сообщений: 2654 |
на уровне use case и диаграммы взаимодействия - вполне. ничего там непонятного нет. а остальное всё (ER, классы) бизнесу не интересно |
||
17 апр 19, 10:47 [21864582] Ответить | Цитировать Сообщить модератору |
WebSharper Member Откуда: Сообщений: 505 |
Диаграммы на UML удобны как иллюстрация - чтобы нарисовать на доске коллеге при обсуждении дизайна, как часть документации для программистов, для описания паттернов проектирования и т.д.
Насчет обсуждения задачи с заказчиком, не знаю. Я думаю для описания бизнес процессов какая-нибудь swimlane diagram будет вполне себе понятна с небольшими объяснениями, но сам не пробовал.
Поддерживать постоянную модель всего в UML мне не представляется разумным - чтобы удобно работать с диаграммами надо не только описывать модель, но и размещать эти квадратики, чтобы стрелочки пересекались поменьше и т.д. - мне кажется в этом нет особого смысла. |
||
17 апр 19, 10:50 [21864586] Ответить | Цитировать Сообщить модератору |
МодальноеОкно Member Откуда: Сообщений: 2654 |
если в вашей диаграмме пересекаются стрелки - она гавно (с) один мудрый аналитик |
||
17 апр 19, 10:52 [21864592] Ответить | Цитировать Сообщить модератору |
Bsplesk Member Откуда: Сообщений: 139 |
Тема на самом деле "холливарная", я за умеренное/разумное применение UML. На моей практике - бизнес отлично - без обучения понимает USE CASES. Причем совсем не обязательно рисовать "огурчики" достаточно оформить в виде "Содержания"/CASES-->[GROUP XX]-->CASE XXX. Но "диаграмма" с "огурчиками" лучше передает обзорную картину, что условная роль (да-да роли/права enterprise) "Вася" делает XYZ, а "Петя" ABCDE, а "Вера" XYDE или вообще динамически, но тогда "огурчики" не нужны. "Пограммисты" отлично понимают activity (граф. отображение алгоритмов) - без доп. обучения и sequence (это больше для интеграции) с обучением 30 мин. на объяснение "альтернативных" сценариев. Что касается Class Diagram - на моей практике если есть задачи, которые требуют необходимость генерации кода (причем под "кодом" может подразумеваться шаблон документа/меню интерфейса), то UML вполне, как один из вариантов. Другими вариантами могут быть xml schema+xlst/json schema (есть хочется приключений) или "IDL" какого-нибудь "чудного" шаблонизатора, который может "сдохнуть" еще до окончания проекта. p.s. Программировать бизнес логику на UML не предлагаю - для этого лучше подходят бизнес правила/drools, dmn .. etc. |
17 апр 19, 11:32 [21864661] Ответить | Цитировать Сообщить модератору |
Bsplesk Member Откуда: Сообщений: 139 |
p.s. Для обсуждения процесса с бизнесом к дополнению к тексту есть BPMN (гораздо человечнее UML) и для бизнеса достаточно. Для "Общего введения" есть продающие презентации в "картинках с котиками" аля "мемы". |
17 апр 19, 11:50 [21864705] Ответить | Цитировать Сообщить модератору |
mad_nazgul Member Откуда: Сообщений: 4972 |
Был у меня один проект, где аналитик нарисовал страниц то-ли 15 то-ли 20 USE-CASE диаграмм. Причем в предметной области как бы должен был шарить. "Заказчик" с умным видом покивал головой. Начали мы делать все по диаграммам, точь-в-точь. В общем бизнес процессы там были нарисованы, какие вообще не существовали никогда. Аналитик через месяц "смылся". Поставили "парня от сохи". Т.е. кто реально работал и знал все бизнес процессы "изнутри". Он нам (программистам) "на пальцах" объяснял что и как работает. Мы это быстро делали. Так что "заказчик" понимает USE-CASE - это слишком оптимистичное предположение. |
||||
17 апр 19, 12:00 [21864732] Ответить | Цитировать Сообщить модератору |
mad_nazgul Member Откуда: Сообщений: 4972 |
BPMN это вообще "АДъ и Израиль". Потому что в лучшем случае на нем описывают "успешный сценарий". А вот что делать при тех или иных ошибках или сбоях, обычно "забивают". Опять же картинка получается "вумная" много квадратиков, стрелочек. "Заказчик" делает вид, что "да так мы и работаем". А потом "ваша программа не правильно работает!!!!!" |
||
17 апр 19, 12:05 [21864740] Ответить | Цитировать Сообщить модератору |
МодальноеОкно Member Откуда: Сообщений: 2654 |
и чо? вы собрали все паттерны "как не надо делать". теперь пытаетесь натянуть сову на глобус? |
||||
17 апр 19, 12:08 [21864746] Ответить | Цитировать Сообщить модератору |
МодальноеОкно Member Откуда: Сообщений: 2654 |
казалось бы - причем тут нотация |
||
17 апр 19, 12:09 [21864748] Ответить | Цитировать Сообщить модератору |
WebSharper Member Откуда: Сообщений: 505 |
А можете сказать в чем человечнее? Вы сравниваете голый UML или профиль для бизнес моделирования? |
||
17 апр 19, 14:00 [21864982] Ответить | Цитировать Сообщить модератору |
mad_nazgul Member Откуда: Сообщений: 4972 |
Идеальных заказчиков не существует. А UML это язык который надо знать и понимать. И надеяться на то что "заказчик" знает и понимает UML - наивно. |
||
17 апр 19, 14:58 [21865096] Ответить | Цитировать Сообщить модератору |
mad_nazgul Member Откуда: Сообщений: 4972 |
При том, что BPMN - это ЯП, а не нотация. А программировать надо уметь и надеяться, что "заказчик" умеет программировать - наивно. |
||||
17 апр 19, 15:01 [21865104] Ответить | Цитировать Сообщить модератору |
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7 8 вперед Ctrl→ все |
Все форумы / Разработка информационных систем | ![]() |