Здравствуйте, Merle, Вы писали:

M>Здравствуйте, byur, Вы писали:

B>> Для тогд чтобы спроектировать domain model мне ну никак не нужно знать особенностей языка ... ей-богу!
M>Значит толку ноль от такой Domain Model

Толк это вещь сложная, неопределенная и непонятная. Проще говорить что Domain Model по определению вообще независит от реализации .

B>>1. Чтобы сначала увидеть лес, а потом интересующие меня деревья.
M>Ну не нужен для этого еще один язык.

Как сказать ... Можно почитать статью от MS в архитектурном журнале .. Secrets of Great Architects -- так они там все в UML приводят про подход от общего к частному, с постепенной детализацией. Кстати -- это к вопросу о том что MS игнорирует UML .

B>>ОК ... ну не знаю я Smalltalk-а ... как мне понять суть системы на нем написанной???
M>Значит надо взять архитектора, который знает SmallTalk.

Да гдеж его взять-то милого ... в нашей деревне нету таких

B>> А при наличии внятной модели на UML в сочетании с требованиями, да еще оттрассированной дизайном на требования -- мне все станет понятно ...
M>И что толку от такого понимания? Что с этим пониманием делать-то дальше?

Вестимо, что -- на ее основе строить новую . Про legacy systems наверное все наслышаны.

Здравствуйте, Merle, Вы писали:


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

Что там сложного-то??? Уж не сложнее языков программирования .

Здравствуйте, Mystic, Вы писали:

AF>>>>Ну а если в коде реализована не вся необходимая функциональность?

M>>>Тут возможны варианты

AF>>Какие? Мистически домыслить что имелось в виду?
AF>>Очевидно, что без описания модели или иного источника информации о том, что нужно делать — вариантов никаких.

M>Никаких это слишком категорично. Я вот просматриваю исходники FireBird, и до сих пор не наткнулся на описание модели. Но продукт развивается понемногу... Работа программиста состоит в том, чтобы как раз изменять и дописывать функциональность. Не все при этом используют UML. Ты как-то сам видишь, что надо поменять и как. Некие общие моменты архитектуры хранятся в голове, постоянно сверять их с диаграммами есть потеря времени. Это модель строится на базе опыта работы над проектом, внесенных ранее изменений. Возможно на этапе изучения этой архитектуры (чтобы войти в курс дела) UML мог бы помочь. Но все равно, войти в курс дела без исходного кода мне представляется нереальным. А далее обычно идет неформализованый процесс, когда ты и так видишь, что надо сделать для того, чтобы добавить нужный кусок. Либо примерно преставляешь, где реализованонечно похожее по своей функциональности, чтобы взять его а образец. Откуда приходят в голову мысли? А кто его знает...

Различаем твёрдое и блестяшее...
То, что вы говорите — это высокое исккуство ваяние того, что вам взбрело в голову. А я говорю о воплощении в жизнь вполне конкретного замысла. Именно его а не какого либо другого. Так вот если этот замысел нигде не описан, у вас лишь код, который реализует лишь кусок замысла ди и тот возможно — неправильно, в чём замысел заключался узнать не возможно — тогда вариантов нет. Так вот для того, что бы не попасть в такую ситуацию — документы и пишут. На определённом уровне — используют диаграммы.

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, AndreyFedotov, Вы писали:


AF>> UML то тут причём?
M>При том, что не зная языка разработки архитектору остается только в UML-е модельки ваять.

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

AF>> Берём архитектора, который всё рисует на бумажке, разработчиков с квадратными глазами, которые не фига не понимают, но вовремя кивают, и получаем тот же самый результат — с теми же последствиями.
M>Тот же самый результат не получим, так как архитектор, разбираясь в исходниках, сразу поймет, что ему "дуру гонят" и объяснит так, чтобы поняли.

Вам тогда не архитектор нужен а просто толковый дивелопер. Давайте вещи своими именами называть .

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, AndreyFedotov, Вы писали:


AF>> UML то тут причём?
M>При том, что не зная языка разработки архитектору остается только в UML-е модельки ваять.
И что? Чему это мешает?

AF>> Берём архитектора, который всё рисует на бумажке, разработчиков с квадратными глазами, которые не фига не понимают, но вовремя кивают, и получаем тот же самый результат — с теми же последствиями.
M>Тот же самый результат не получим, так как архитектор, разбираясь в исходниках, сразу поймет, что ему "дуру гонят" и объяснит так, чтобы поняли.
И тот же архитектор будет проверять разводку печатных плат, что бы удостовериться в том, что аппаратная часть комплекса тоже сделана верно? Что дальше — он будет вскрывать корпуса чипов?
Да и проверку кода даже 10 человек я представляю с большим трудом. Разве что архитектору делать на самом деле нечего и он так называется для понта. А на самом деле — обычный старший программер...

Здравствуйте, byur, Вы писали:

B> Вы просто выражаете свои проектные мысли на этом языке ... это несколько удобнее, например для обсуждения проектных решений, чем использование кода ... особенно, если мы еще до кода не добрались.
Чем может быть удобнее два языка, когда можно обойтись одним?

Здравствуйте, _Obelisk_, Вы писали:

_O_>Еще один пример существует.
Ну, это все явления одного порядка, когда UML используется не для документирования, а в качестве основного языка разработки.

Здравствуйте, AndreyFedotov, Вы писали:

AF>И что? Чему это мешает?
Не правильно вопрос ставите, чему это помогает? Кому нужны модели, которые не имеют ничего общего с реальной системой?

AF> А на самом деле — обычный старший программер...
Хоть горшком назови, какой тол от рахитектора, который кроме рисования диаграмок ничего не умеет?

B>Толк это вещь сложная, неопределенная и непонятная. Проще говорить что Domain Model по определению вообще независит от реализации .

я конечно понимаю, что знание какого либо языка (даже UML) не обязательно для описания процессов происходящих в жизни, буть то тех-процессы, бизнес-процессы, то что описывает автоматизируемую систему, в случае автоматизации чего-либо, но ведь это не архитектура ПО.
И безусловно из вашей модели предметной области ну никак однозначно програмную систему построить нельзя, без промежуточных этапов проектирования. А знания языка, ОС, и прочего на этапе проектирования для реализации по-моему просто необходммы... Как вы будете проектировать 3D реадктор скажем, не зная о сушествовании OpenGL и DirectX, а также их особенности, или как вы будете проектировать не зная что в C++ возможно множественное наследование, а в Object Pascal нет, и даже наследование интерфейсов не возможно множественное. Модель модели рознь, и моё мнение таково что модель должна быть построенна так чтобы максимально описывать объект с минимальными затратами на её создание. Я не уверен что описание бизнес-процессов в производстве удобнее представить в виде UML, и затем демонстрировать это управляющему производством или президенту автоматизируемой компании... или вы их UML обучать будете...

B>>>1. Чтобы сначала увидеть лес, а потом интересующие меня деревья.

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


B>>>ОК ... ну не знаю я Smalltalk-а ... как мне понять суть системы на нем написанной???

1) взять документацию по системе. А если вам нужно внедрение в систему или переработка, взять книги по SmallTalk, изучить Smalltalk.


M>>Значит надо взять архитектора, который знает SmallTalk.
B>Да гдеж его взять-то милого ... в нашей деревне нету таких

см (1).

p.s. Я не утверждал что использовать UML не возможно или нельзя, я говорил что пользоватся средствами создания и поддержки UML-проектов крайне не удобно, перенося это на язык я говорил что UML (как методологией) пользоваться также не удобно. Безусловно ей пользуются, потому что лучшего нет, хотя сомнительно ибо карандаш-бумага иногда всё таки выразительней и понятней для всех участников, особенно небольшой команды. В больших работать не довелось и спорить я не буду на эту тему. Я просто глубоко уверен что можно создать средство значительно удобнее UML, но к сожалению до сих пор не создано, вероятно потому что одни считают его вовсе не нужным, другие свято верят в его идеалистичность.

Здравствуйте, AndreyFedotov, Вы писали:

AF> Это далеко не всегда возможно. Простой пример: разработка крупного программно-аппаратного комплекса. В таком комплексе зачастую одни и теже алгоритмы реализуются на различной аппаратуре, причём видов этой аппратуры — 30-40. Система структурируется и каждый уровень должен быть грамотно описан, что бы различные разработчики делали аппаратуру под один и тот же стандарт. Тем более, если часть аппратуры или ПО разрабатываются вовне — в другом городе и тем более стране. Вот и попробуй в таких условиях выделить 20-30 человек, которые всё сделают...

А описывается стандарт или алгоритмы?

AR>Разные разделы математики по-разному воспринимаются без картинок. Например дифгеометрию довольно трудно понять без этого. А теория супструн, основанная, кстати, во многом именно на дифгеометрии, — книга отнюдь не понятная. Возможно именно из-за того, что авторы местами пренебрегают графическим средствами иллюстрации своих мыслей. Тому, кстати, есть довольно банальные причины, в корне которых лежит нестандартность этих картинок. Рисование нестандартных (а в теории супструн и дифгеометрии таких стандартов нет) картинок и графических элементов отнимает уйму времени и требует достаточно высокой квалификации от верстальщика (и издатели обычно перекладывают эту работу на самих авторов, а авторы, где могут, избегают это делать).

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

B>>>Если я проектировщик/архитектор, то я не рассуждаю на уровне кода ... а напрягаться чтолы восстановить все из сырцов как-то не очень хочеться.
Я вот проектировщик/архитектор. И мне проще выделить базовый код архитектуры, чтобы он не перемешивался с остальным, чем строить абстрактные схемы "не ... на уровне кода". Более того, иногда приходится следить, что архитектура соблюдается. И тут опять же, без выделенного уровня будет тяжело.

B>Выдержка из вашего сайта о вас же ...
Я, хоть во многом с Mystic'ом не согласен, но, всё же, это уже переход на личности. Вам что, кроме этого, больше нечего сказать по содержанию?

B>Конечно программируя в Дельфи вы врядли используете UML ...
Аналогичный наезд. Ну и зачем? Для этого здесь отдельный есть форум.

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

AF>И что в 10% кода содержится описание того, что должно быть в остальных 90%?
AF>Вселенная, конечно, фрактал, но не до такой же степени...
Вселенная — нет. А грамотно спроектированный код — да. Вот те 90% "мешающегося" при понимании архитектуры кода очень легко спрятать. Этот давно известный приём ООП называется "инкапсуляция".

AF>Различаем твёрдое и блестяшее...
AF>То, что вы говорите — это высокое исккуство ваяние того, что вам взбрело в голову. А я говорю о воплощении в жизнь вполне конкретного замысла. Именно его а не какого либо другого. Так вот если этот замысел нигде не описан, у вас лишь код, который реализует лишь кусок замысла ди и тот возможно — неправильно, в чём замысел заключался узнать не возможно — тогда вариантов нет. Так вот для того, что бы не попасть в такую ситуацию — документы и пишут. На определённом уровне — используют диаграммы.

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

AF>Отцам основателям это удавалось. Секрет в том, что бы знать принципы построения языков и архитектуру используемых библиотек, а вот синтаксис — вовсе не обязательно...
Да нормального уровня программист этот синтаксис освоит за неделю. А в течение месяца работы и фишечки. Уж никак незнанание языка не мешает писать программу. И архитектуру соответственно строить. А если её начинать строить сразу в коде — то на препятствия, налагаемые языком, можно быстро наткнуться и подработать архитектуру. А если её спустить программистам сверху, не зная языка, они будут вынуждены в коде писать какие-то ужасы, которые нафиг не нужны. Простой пример, напроектировать чего-то с применением обратных вызовов при использовании DCOM. Оно, конечно, пишется, но, как правило, проще использовать другое решение. И это — тот случай, когда нужно знать особенности даже не языка, а среды.

AF>Затем, что любой язык, который применяется не для живого общения, а для документации — которую может читать специалист не знакомый с автором опуса, должен быть описан. Когда вы обясняете что то в живую вы как правило неявным образом договариваетесь о системе обозначений. Потому вас понимают и вы понимаете. Если что-то не понятно — вы можете об этом спросить отдельно. А теперь представьте, что вам принесли диаграмму — на которой неизвестные вам обозначения и спросить некого
Ну этот десяток стрелочек (уж если захотелось что-то рисовать, а не использовать великий и могучий) — описать совсем не проблема. На это уйдёт час. А на освоение UML?

M>>Я полагаю, что нет такой информации о проекте, которая не выразима исходным кодом.
Я тоже согласен. Однако, это верно для очень квалифицированного программиста.

AR>В каком-то смысле я вам сочуствую. Вам просто не попадались действительно талантливо и профессионально сделанные книги (причем не важно на какую тему). При обучении по разным учебникам колоссальная разница в скорости понимания и усвоения написанного заставляет задуматься о причинах этого. Уверяю вас, содержательные и к месту сделанные иллюстрации играют здесь не последнюю роль. А ведь как правильно заметили другие участники обсуждения, в случае программной системы есть и такие вещи как порядок развертывания, базовые описания предметной области, и много чего такого, что исходный в его сегодняшнем состоянии не может содержать.
Даже на этом уровне текстового описания более чем достаточно. И оно более понятно.

B>Это смотря что вы понимаете под проектированием. В RUP, например, есть понятие модели анализа, модели дизайна и модели имплементации. Модель анализа независима от платформы/языка разработки ... модель дизайна совершенно спокойно модет быть сделана тоже независимой (это лишь вопрос квалификации проектировщика). А вот модель имплементации -- это уже с которой можно генерить исходный код на конкретном языке. Отсюда вывод -- можно, пользуясь вашим термином, ГРАМОТНО спроектировать систему, не зная досконально конкретные языки программирования, как минимум на уровне моделей анализа и дизайна. А имплементацию норамальный разработчик уже на конкретном языке сам напишет , оптимизируя вызовы и прочия ....

Я правильно понимаю, что модель анализа — это ещё вовсе не архитектура классов? А всего лишь чётко выделенная структура предметной области?
И то, что модель дизайна может быть независимой — это накладывает ограничения общность её описания? Т.е. я так понимаю, там не должно быть подробного описания взаимодействия объектов. Скорее уж описание модульного разделения системы и взаимодействия модулей. Так?

Здравствуйте, nixite, Вы писали:

N>Я не утверждал что использовать UML не возможно или нельзя, я говорил что пользоватся средствами создания и поддержки UML-проектов крайне не удобно, перенося это на язык я говорил что UML (как методологией) пользоваться также не удобно. Безусловно ей пользуются, потому что лучшего нет, хотя сомнительно ибо карандаш-бумага иногда всё таки выразительней и понятней для всех участников, особенно небольшой команды. В больших работать не довелось и спорить я не буду на эту тему. Я просто глубоко уверен что можно создать средство значительно удобнее UML, но к сожалению до сих пор не создано, вероятно потому что одни считают его вовсе не нужным, другие свято верят в его идеалистичность.

Целиком поддерживаю, когда речь идет именно о процессе разработки. Использовать методологии UML для разработки неудобно и накладно, а тем более в небольших проектах. Нужны иные средства (Together и DSL вероятно как раз и есть движение в нужном направлении). В то же время нет никакого смысла заменять UML как средство визуализации. Возвращаясь к своей аналогии с PDF замечу, что все согласны использовать PDF-документы, когда надо обеспечить народ информацией. Но вот писать тексты сразу в формате PDF никто особо не стремится — все больше Word или другие текстовые редакторы пользуем.

Здравствуйте, Сомов Александр, Вы писали:

AF>>Различаем твёрдое и блестяшее...
AF>>То, что вы говорите — это высокое исккуство ваяние того, что вам взбрело в голову. А я говорю о воплощении в жизнь вполне конкретного замысла. Именно его а не какого либо другого. Так вот если этот замысел нигде не описан, у вас лишь код, который реализует лишь кусок замысла ди и тот возможно — неправильно, в чём замысел заключался узнать не возможно — тогда вариантов нет. Так вот для того, что бы не попасть в такую ситуацию — документы и пишут. На определённом уровне — используют диаграммы.

СА>А вот тут, по-моему, достаточно хорошо структурированных требований. Вот без них действительно никуда. Но эти требования легко пишутся на обычном русском языке и, как правило, не содержат каких-нибудь связей с архитектурой системы.

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

Здравствуйте, Сомов Александр, Вы писали:

СА>... Уж никак незнанание языка не мешает писать программу. И архитектуру соответственно строить. А если её начинать строить сразу в коде — то на препятствия, налагаемые языком, можно быстро наткнуться и подработать архитектуру. А если её спустить программистам сверху, не зная языка, они будут вынуждены в коде писать какие-то ужасы, которые нафиг не нужны. Простой пример, напроектировать чего-то с применением обратных вызовов при использовании DCOM. Оно, конечно, пишется, но, как правило, проще использовать другое решение. И это — тот случай, когда нужно знать особенности даже не языка, а среды.

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

СА>Ну этот десяток стрелочек (уж если захотелось что-то рисовать, а не использовать великий и могучий) — описать совсем не проблема. На это уйдёт час. А на освоение UML?

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