Здравствуйте, Сомов Александр, Вы писали:
СА>>>Всё-таки, даже если в математических книгах и есть картинки, то они описывают не структуру формул, а, грубо говоря, результат их применения. А вот тот же UML — описывает как раз-таки более структуру. Аналогом картинок из математических книг в программировании были бы screenshot'ы.
AF>> То есть диаграмма последовательности взаимодействия двух систем друг с другом ближе к реальному коду, с его кучей ньансов, чем к обобщённому логическому описанию процесса?
СА>А по вашему код должен выглядеть совсем не так? Мой код структурно очень близок к предметной области. И тут можно выделить последовательность взаимодействия в виде высокоуровневых операций в коде.
То есть в твоём коде отсутствуют ключи, идентификаторы, указатели или ссылки — в общем всё то, что отсутствует в предметной области?
Интресно — и как он при этом работает?
Здравствуйте, Сомов Александр, Вы писали:
СА>Здравствуйте, AndreyFedotov, Вы писали:
AF>>Здравствуйте, Сомов Александр, Вы писали:
AF>>>>И что в 10% кода содержится описание того, что должно быть в остальных 90%? AF>>>>Вселенная, конечно, фрактал, но не до такой же степени... СА>>>Вселенная — нет. А грамотно спроектированный код — да. Вот те 90% "мешающегося" при понимании архитектуры кода очень легко спрятать. Этот давно известный приём ООП называется "инкапсуляция".
AF>>То есть вы возмьмётесь доволдить до победного конца проект, в котором описано 10% интерфейсов, классов и кода — без какой либо документации или других источников информации о том, что нужно делать? СА>Не так, 10% кода должны отражать логику работу, а 90% — нюансы.
Про должны — это теория. А если не отражают? А если, как это часто бывает, зказчик хочет, что бы сначала заработала часть функционала, а потом делалось всё остальное — и именно этот кусок + обвязка которая ему нужна и реализованы?
СА>Насчёт доводить — функциональные требования нужны всегда, а с ними — да, возьмусь. В этой области UML один из инструментов описания и даже не самый удобный.
То есть тезис о том, что кода достаточно вы только что сами же и отвергли...
СА>Опять же, из функциональных требований, которые сами по себе не требуют UML.
Да, как уже многократно говорилось, обойтись можно. И в зависимости от ситуации это будет разумно использовать UML или не использовать.
СА>А из грамотно написанного, работающего кода я могу извлечь описание функциональности. Разумеется, то, что в коде не содержится, не будет отражено.
То есть нужна документация описывющая модель. СА>Но в этом случае, если была бы документация, то она просто не соответствовала системе. А когда она полностью соответствует, то она становится ненужной (при условии, что код написан хорошо). Причём ненужной, как документация, — необходимость остаётся при разборе дефектов. Но тут опять же архитектурный UML никаким боком не вылазит, достаточно словесных описаний.
Система может быть написана плохо и действительно не отражать модель. Но ценность часто имеет именно модель, а не сам код — особенно в крупных проектах.
Здравствуйте, Сомов Александр, Вы писали:
СА>Здравствуйте, AndreyFedotov, Вы писали:
AF>>Здравствуйте, Сомов Александр, Вы писали:
AF>> Вот именно после такого поверхностного освоения за неделю и рождаются монстры, которых потом программистам приходится потом и кровью выписывать. А простая мысль поговорить с программистами — которые всяко лучше разбираются в технологии — в голову не приходила? СА>Да вовсе нет. Своевременный грамотный рефакторинг ещё и из не таких дыр выбраться позволяет. Хуже, когда упорно пишутся всё новые и новые абстракции под архитектуру, которая ну никак не соответствует выбранной среде. Я год жил с такой спущенной сверху архитектурой. В итоге, её просто выкинули, а программа была отрефакторена. С тех пор она быстро и качественно развивается.
То есть вы нарушили ключевое условие: учёт особенностей архитектуры выбранной среды. Опять таки — это имеет отношение к среде, но не к языку. Исходный тезис был про знание синтакиса языка. Про особенности архитектуры ничего не говорилось.
AF>> Потом дело совсем в другом. Архитектуру в сложной системе нужно описывать так, что бы от кода вообще не зависела. Тут знание языка вообще может быть вредным — так как появляется тенденция подгонять архитектуру под сиюминутные потребности. Кроме того пример с DCOM как раз иллюстрирует ключевой момент о котором я и говорил: AF>>
AF>>Секрет в том, что бы знать принципы построения языков и архитектуру используемых библиотек, а вот синтаксис — вовсе не обязательно...
СА>Да... на самом деле, я понял, мы почти об одном говорим. Просто нынче первая используемая библиотека идёт чуть ли не с языком в поставке. Вот я её имел в виду, когда писал. Вот её — да, нужно знать. Но если так, то у нас архитектура строится библиотекозависимо. А это достаточно серьёзная привязка к тому же языку, например. Это знания всё равно будут соседствовать. Т.е. это ещё не тот уровень, который не зависит от окружения. Если так, то много нюансов окружения придётся включать в архитектуру. И, опять же, разве не код (ну и, где совсем необходимо, текстовое описание) может содержать эти нюансы.
Совершенно верно. С поправкой на то, что библиотека может быть инвартантна по отношению языку (.NET) или по отношению к платформе (QT).
Потому тут три наиболее характерных пути. Первый — когда мы согласны с привязкой к библиотеке/платформе — тогда мы можем подгонять архитектуру под её особенности. В мелком проекте так обычно и делается. Второй — когда нам требуется инвариантность к библиотеке/платформе. В этом случае разрабатывают API — который должен обеспечивать эту инвариантность и архитектура делается под него. И наконец, в крупных и дорогих проектах требуется инвариантность по отношению к реализации нижележащих уровней. В этом случае на верхнем уровне архитектура может быть сколь угодно абстрактна и до определённой степени вообще игнорировать какие-либо особенности платформ.
СА>Можно ведь и архитектуру поддерживать, и картинки не рисовать. Высокоуровневая (модульная) архитектура и так практически от кода не зависит, а уровень взаимодействия объектов внутри модулей в программе меняется уже без особых усилий. И заранее нужно писать именно высокоуровневую архитектуру и там не то, что картинок, а текста-то на страничку — две. А внутримодульный уровень писать отдельно от кода смысла нет.
Теория. Такое возможно только в мелкой системе. В крупной это уже 20-30 страничек, если не 200-300.
AF>>Вы хотите сказать, что архитектор или разработчик, которые легко за неделю осваивают синтаксис нового языка не в состоянии за ту же неделю понять, что означает десяток стрелочек? СА>Освоит. Но зачем? До кучи?
Для того, что бы понимать друг-друга даже если мысли описаны на бумаге...
Здравствуйте, Alexey Rovdo, Вы писали:
AR> Вы высказываете примерно те же мысли, которые я пытался объяснить в самом начале этого спора.
С этими мыслями никто и не спорит, не соглашаются с другим Ваши утверждением, что UML хорошо подходит для документирования готового кода.
Тут во-первых сама посылка не верна, хороший код не нуждается в документировании, а во-вторых, идея не удачна, уж если документировать то нет смысла изобретать для этого новый язык.
Здравствуйте, bralgin, Вы писали:
B>Здравствуйте, ВСЕ УЧАСТНИКИ ОБСУЖДЕНИЯ, Вы писали:
B>Господа! Предлагаю определится с терминологией! А то, похоже, каждый под архитектурой понимает что-то свое: B>кто бизнес логику, кто иерархию объектов, etc.
Совершенно верно. А заодно и о том, о каких системах идёт речь. Так как налицо когда сопоставляются методы для разработки бухгалтерских программок на месяц работы и крупных аппаратно-программных компелксов на 1000 человеколет.
Здравствуйте, AndreyFedotov, Вы писали:
AF> То есть вы нарушили ключевое условие: учёт особенностей архитектуры выбранной среды.
Не нарушили, а как раз наоборот. Учета не было с самого начала, а потом переделали с этим учетом.
AF>Исходный тезис был про знание синтакиса языка.
Исходный тезис был вообще не про синтаксис, а про умение программировать на уровне своих разарботчиков на языке на котором будет вестись разработка.
AF> Для того, что бы понимать друг-друга даже если мысли описаны на бумаге...
Для этого UML не нужен.
СА>>А по вашему код должен выглядеть совсем не так? Мой код структурно очень близок к предметной области. И тут можно выделить последовательность взаимодействия в виде высокоуровневых операций в коде.
AF>То есть в твоём коде отсутствуют ключи, идентификаторы, указатели или ссылки — в общем всё то, что отсутствует в предметной области? AF>Интресно — и как он при этом работает?
Хм... да ведь это же всё, что запятые в тексте. Читать-то нисколько не мешают.
Вот когда там появляется дополнительная логика или нюансы — это хуже. Они скрывают общую логику. Ну так их можно отделить, инкапсулировать во что-нибудь, чтобы в глазах не маячили. А основной код остаётся лакончным и близким к предметно области.
К тому (можно я тоже попередёргиваю ) — в предметной области, как правило и стрелочек с рамочками нет.
AF>>>То есть вы возмьмётесь доволдить до победного конца проект, в котором описано 10% интерфейсов, классов и кода — без какой либо документации или других источников информации о том, что нужно делать? СА>>Не так, 10% кода должны отражать логику работу, а 90% — нюансы. AF> Про должны — это теория. А если не отражают? А если, как это часто бывает, зказчик хочет, что бы сначала заработала часть функционала, а потом делалось всё остальное — и именно этот кусок + обвязка которая ему нужна и реализованы?
Да какая разница — какое там отношение процентное. Просто код, отражающий нюансы, должен быть инкапсулирован. А то, что останется — читать несложно. И поддерживать несложно.
А что касается написания части функциональности — есть две модели: гибкая и негибкая. В первой мы не будем писать дополнительный код сверх части функционала (тоже неплохо, а вдруг потом заказчик обанкротится, а так — мы не затратим лишних усилий ), а во второй — запланируем сразу. По моим ощущениям (даже и не расчитывайте на объективность мнения ) — временные затраты в первом случае (плюс рефакторинг и доведение до полного функционала) и во втором случае (полная архитектура, часть функциональность, доведение до полной) будут примерно одинаковы. А вот риск в первом случае вроде как меньше. Хотя он тоже растёт с ростом величины проекта.
СА>>Насчёт доводить — функциональные требования нужны всегда, а с ними — да, возьмусь. В этой области UML один из инструментов описания и даже не самый удобный. AF> То есть тезис о том, что кода достаточно вы только что сами же и отвергли...
Для понимания архитектуры — достаточно, для развития и исправления дефектов — недостаточно.
СА>>Опять же, из функциональных требований, которые сами по себе не требуют UML. AF> Да, как уже многократно говорилось, обойтись можно. И в зависимости от ситуации это будет разумно использовать UML или не использовать.
Ну вот. А я предлагаю структурировать код, чтобы и архитектура (не функциональные требования) им же просто и описывалась. Чтобы этот не очень удобный инструмент (UML то есть) и вовсе не был нужен.
СА>>А из грамотно написанного, работающего кода я могу извлечь описание функциональности. Разумеется, то, что в коде не содержится, не будет отражено. AF> То есть нужна документация описывющая модель. СА>>Но в этом случае, если была бы документация, то она просто не соответствовала системе. А когда она полностью соответствует, то она становится ненужной (при условии, что код написан хорошо). Причём ненужной, как документация, — необходимость остаётся при разборе дефектов. Но тут опять же архитектурный UML никаким боком не вылазит, достаточно словесных описаний. AF> Система может быть написана плохо и действительно не отражать модель. Но ценность часто имеет именно модель, а не сам код — особенно в крупных проектах.
А как хорошо, когда там ещё и код модель отражает.
Мы же не говорим о том, как быть с уже написанной лапшой, мы говорим, как писать код так, чтобы он не требовал (или требовал минимум) подобных дополнений.
Как работать с лапшой — это уже совсем другая головная боль.
AR>> Вы высказываете примерно те же мысли, которые я пытался объяснить в самом начале этого спора. M>С этими мыслями никто и не спорит, не соглашаются с другим Ваши утверждением, что UML хорошо подходит для документирования готового кода. M>Тут во-первых сама посылка не верна, хороший код не нуждается в документировании, а во-вторых, идея не удачна, уж если документировать то нет смысла изобретать для этого новый язык.
Код — не нуждается. А функциональность нуждается. Иначе у нас нет эталона, к которому приводить код.
А про второе, насколько я понял, Alexey Rovdo и не говорит.
AF>>> ...пропущено...
Почти согласен.
AF>>>Вы хотите сказать, что архитектор или разработчик, которые легко за неделю осваивают синтаксис нового языка не в состоянии за ту же неделю понять, что означает десяток стрелочек? СА>>Освоит. Но зачем? До кучи? AF> Для того, что бы понимать друг-друга даже если мысли описаны на бумаге...
Возможно. Но лучше освоить настолько же родной язык и свои же мозги. Это как из неверных UML картинок получаются неверные программы, так и из каши в голове получается каша. А какая разница — будет она в словах или в картинках. А если всё чётко — слов более чем достаточно.
Проблема ведь, как правило, не в том, UML или не UML, а в том, работает голова как надо или нет. А UML — один из (и не более того) инструментов. Вовсе не обязательный и не всегда удобный. Я бы вообще не стал утверждать, что он где-то особо нужен или напротив не применим. Но вот я его не выбрал. И не использую. Он мне не нравится. И бумажек со словами хватает.
Сама концепция — общего языка — очень неплохая. Реализация — не тянет. Да и дублирование, мне кажется, на этом пути можно устранить, совместим архитектуру и код. Для этого и то и то нужно править. Нынешние языки не очень хорошо для совмещения подходят, UML — тоже.
Здравствуйте, AndreyFedotov, Вы писали:
AF>Здравствуйте, bralgin, Вы писали:
B>>Здравствуйте, ВСЕ УЧАСТНИКИ ОБСУЖДЕНИЯ, Вы писали:
B>>Господа! Предлагаю определится с терминологией! А то, похоже, каждый под архитектурой понимает что-то свое: B>>кто бизнес логику, кто иерархию объектов, etc.
AF>Совершенно верно. А заодно и о том, о каких системах идёт речь. Так как налицо когда сопоставляются методы для разработки бухгалтерских программок на месяц работы и крупных аппаратно-программных компелксов на 1000 человеколет.
Ну. Так сразу всё интересное кончится, потому что будет сразу видно, что в одних случая UML хорошо применяется, а в других — не очень, и потому все и спорят.
AF>>Исходный тезис был про знание синтакиса языка. M>Исходный тезис был вообще не про синтаксис, а про умение программировать на уровне своих разарботчиков на языке на котором будет вестись разработка.
Согласен.
AF>> Для того, что бы понимать друг-друга даже если мысли описаны на бумаге... M>Для этого UML не нужен.
Ещё раз согласен.
Здравствуйте, Сомов Александр, Вы писали:
AF>>Совершенно верно. А заодно и о том, о каких системах идёт речь. Так как налицо когда сопоставляются методы для разработки бухгалтерских программок на месяц работы и крупных аппаратно-программных компелксов на 1000 человеколет.
СА>Ну. Так сразу всё интересное кончится, потому что будет сразу видно, что в одних случая UML хорошо применяется, а в других — не очень, и потому все и спорят.
А так тут оказывается процесс главное! Спор ради спора? Ну тогда радуйтейсь — вы победили! I'm quit
AF>А так тут оказывается процесс главное! Спор ради спора? Ну тогда радуйтейсь — вы победили! I'm quit
Да ладно. Это я иронизирую по поводу появления вопроса, который практически и является решением проблемы.
А на самом деле все к одному мнению не придут. То пользы — только разные точки зрения послушать.
Здравствуйте, Сомов Александр, Вы писали:
СА>... Но лучше освоить настолько же родной язык и свои же мозги. Это как из неверных UML картинок получаются неверные программы, так и из каши в голове получается каша. А какая разница — будет она в словах или в картинках. А если всё чётко — слов более чем достаточно. ...
Кстати, мы тут все пишем о тексте, комментариях в коде и на словах. А вот на каком собственно языке должны быть эти комментарии? Мне кажется, что ценность таких стандартов как UML состоит еще и в том, что они позволяют легче переступать банальные языковые проблемы. Все таки UML освоить можно быстрее, чем научиться грамотно излагать свои мысли хотя бы даже по английски.
СА>Сама концепция — общего языка — очень неплохая. Реализация — не тянет. Да и дублирование, мне кажется, на этом пути можно устранить, совместим архитектуру и код. Для этого и то и то нужно править. Нынешние языки не очень хорошо для совмещения подходят, UML — тоже.
Да, сегодня архитектура и код оказались разъединенными. Но вот каким образом их соединить? Представляется три возможных варианта:
1) Расширить возможности UML и инструментария для работы с ним, включив в него возможности для встраивания исходного кода непосредственно в UML-модели (путь описанный _Obelisk_). В таком варианте исходный код может автоматически генерироваться прямо из полной UML-модели.
2) Расширить возможности исходного года и инструментария по работе с исходным кодом с тем, чтобы обеспечить комфортную работу архитекторов именно с исходным кодом, но не на уровне конкретных строк, а на уровне самой модели системы. В таком варианте UML-модели могут автоматически генерироваться из исходного кода. (путь в некотором приближении близкий идиологии Together и DSL).
3) Заменить UML чем-то иным.
Вариант "отказаться от UML и оставить все как есть" я все-таки пропускаю. Что бы выбрали вы?
AR>Кстати, мы тут все пишем о тексте, комментариях в коде и на словах. А вот на каком собственно языке должны быть эти комментарии? Мне кажется, что ценность таких стандартов как UML состоит еще и в том, что они позволяют легче переступать банальные языковые проблемы. Все таки UML освоить можно быстрее, чем научиться грамотно излагать свои мысли хотя бы даже по английски.
А комментарии в коде при том, что код понятен — тоже не нужны. А вот идентификаторы — однозначно на английском. Если что — Lingvo поможет.
СА>>Сама концепция — общего языка — очень неплохая. Реализация — не тянет. Да и дублирование, мне кажется, на этом пути можно устранить, совместим архитектуру и код. Для этого и то и то нужно править. Нынешние языки не очень хорошо для совмещения подходят, UML — тоже.
AR>Да, сегодня архитектура и код оказались разъединенными. Но вот каким образом их соединить? Представляется три возможных варианта: AR>... AR>Вариант "отказаться от UML и оставить все как есть" я все-таки пропускаю. Что бы выбрали вы?
Да в принципе, все три вполне подходят. Только вот кто бы сделал.
Здравствуйте, Alexey Rovdo, Вы писали:
AR>Да, сегодня архитектура и код оказались разъединенными. Но вот каким образом их соединить? Представляется три возможных варианта:
Здравствуйте, Сомов Александр, Вы писали:
СА>>> Однако, это верно для очень квалифицированного программиста. M>>Естественно, но лично я с турдом себе представляю архитектора, который не является квалифицированным программистом... СА>А я об этом и говорю. Да здравствует код! Долой UML!
Гениально. Правда я где то видел обратный лозунг:
Долой код! Да здравствует UML!
Да и денег у них поболее будет...
AR>Да, сегодня архитектура и код оказались разъединенными. Но вот каким образом их соединить? Представляется три возможных варианта: AR>1) Расширить возможности UML и инструментария для работы с ним, включив в него возможности для встраивания исходного кода непосредственно в UML-модели (путь описанный _Obelisk_). В таком варианте исходный код может автоматически генерироваться прямо из полной UML-модели.
Ужаснейший вариант, просто страшно становиться если это кто-то сделает... чем это лучше RAD-средств, абстракция иная только. Представляете как с этим работать...
AR>2) Расширить возможности исходного года и инструментария по работе с исходным кодом с тем, чтобы обеспечить комфортную работу архитекторов именно с исходным кодом, но не на уровне конкретных строк, а на уровне самой модели системы. В таком варианте UML-модели могут автоматически генерироваться из исходного кода. (путь в некотором приближении близкий идиологии Together и DSL).
Были такие интересные идеи помнится, как абстрагироваться от файлов и от места хранения, вроде того что достаточно СУБД по проекту, код представим структурами и классами и навигация идёт не по файлам, что в принципе не очень удобно ибо искуственно разными способами всё группируется и логически выстраивается, а от классов... вобщем идеи явы мне нравятся, реализация вообще не нравится
Из такой концепции однозначно строиться любая UML или что-то иное позволяющее просмотреть взаимодействие классов/объектов, стурктура этих классов и может является с одного представления UML, с другого обычным кодом, редактировать такое будет просто с одной стороны можно графически, с другой текстово... по-моему удобно, возможно это путь DSL, я пока что это не видел.
AR>3) Заменить UML чем-то иным.
я бы выбрал 3. или по крайней мере пересмотреть UML от и до -- рефакторинг вобщем.
p.s. кстати на Use Case мне откровенно смотреть проивно ибо кажется поделкой из десткого сада. Его целесообразность вообще мне сомнительна. Текстовый документ описывающий всё тоже самое более подробно и ясно, займёт меньше места, сэкономит бумагу и время.
Мы уже победили, просто это еще не так заметно...
