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

V>>Т.е., если бы эти утилиты позволяли, например, связать метод статической диаграммы с блок-схемой алгоритма или с параметризируемым шаблоном проектирования (из GoF или кучи еще библиотечных), позволял бы запускать это всё на симуляцию, задавая/играя параметрами алгоритмов — это был бы полноценный САПР.
V>>А так нет.
L>Это означает, что изначально идея подхода неправильная. Ее сделали исходя из примера других индустрий, где сначала — проект, а потом — реализация. Только вот мозгов не хватило понять, что в разработке софта технический проект — это собственно код программы на ЯП а реализация изначально автоматизирована компиляторами.

Забавная ахинея в стиле Шарикова. ))

Изачально ведь был автокод.
Это и был "технический проект"?

А одни из первых вменяемых ЯП — Фортран и Лисп, компилятор только первый.

В общем, коллега, еще не изобрели смайлика, чтобы выразить реакцию на подобные "окровения". ))


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

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

По моим наблюдениям, до глубины иерархии слоёв проектирования примерно 3 человек более-менее справляется.
Относительно алгоритмов — примерно до 7 шагов воспринимается на ура, а если больше — уже не помешает "подсказка" в том или ином виде.
Т.е., когда больше/глубже — начинаются сложности с восприятием.

Поэтому, графические представления никогда из программирования не уйдут.
И не важно, по какой нотации они выполнены.

Даже псевдокод, отбрасывающий детали — тоже разновидность нотации, ведь "это" живёт в независимом от проекта виде.

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

Всё вместе резко помогло.
Реальная практика.


L>Короче, для кода САПР — это IDE со всеми плюшками.

Современные IDE не отвечают определению САПР.
Это, скорее, продвинутые текстовые редакторы исходного кода вкупе с органайзером проектов.


V>>В этом смысле программистские недо-САПР типа Rational Rose и Together позволяли строить разве что, скажем, "проволочную модель", которая прозрачна и статична, не обладает параметрами или свойствами, не допускает симуляции работы, т.е. примерно бесполезна.
L>Не примерно, а не просто бесполезна, но еще и вредна.

В нашем деле вредна лишь категоричность и прочие проявления узости ума.


L>>>А что, дотком — это только веб? У меня для тебя новости.
V>>Бум и затем кризис доткомов (о котором периоде ты упоминал) — это бум и последующий кризис интернет-компаний, ес-но.
L>Иногда нужно и дальше википедии читать.
L>Интернет-компании были только вершиной айсберга. Тогда же почти все конторы обратили внимание на автоматизацию и появившиеся новые технологии, которые позволяли творить разнообразную дичь. Этот бум дал начало куче современных систем.

Увы для тебя, бум автоматизации не совпал с бумом доткомов — он начался примерно на 7 лет раньше.
И не был надутым пузырём — развитие ср-в автоматизации было поступательным.

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

Во времена бума доткомов много на что возложили надежд, не только на UML.
Основные надежды были:
— на быстрое продолжение развитие всемирной сети;
— на продолжение развития быстродействия компьютеров в духе 90-х;
— на продолжение развития интереса к интернету у населения со скоростью, показанной в период 95-2000-й год.

Все три пункта вошли в насыщение в начале 2000-х.
— cетка оказалась для населения дорогой и медленной.
— компьютеры резко замедлили рост быстродействия;
— даже чудовищные инвестиции в доткомы оказались не способны удовлетворить любопытство населения относительно новой технологии — т.е. развитие информационного и операционного наполнения Сети отставало от роста любопытства людей, что в итоге любопытство случилось, считай, однократным.

Но инвестиции в технологии донета не пропали даже с кризисом доткомов.
Пропали инвестиции в некоторые конкретные проекты — ну это такое...

Тут по класике надо понимать во что инвестируешь — в технологию, или в обезъянок, способных лишь использовать технологии, разработанные другими людьми.

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


V>>Если джава, плюсы, дельфи — то да.
V>>И то — плюсы и дельфи с натяжкой, бо в 90-е компонентный подход был более популярен, чем объектный с махровой иерархией наследования, тут только джава резвилась в полный рост, бгг...
L>Еще в начале 90-х на чистых сях писали ООП код. С таблицами виртуальных функций вручную, естественно. В начале нулевых я сам такой проект на плюсы переводил

Но без махровых ООП-иерархий наследования — читай внимательней.

Если ты про таблицу ф-ий драйверов ОС или плагинов в некоторой прикладной системе — это тот самый компонентный подход, т.е. абстракция одного уровня.
Туда же OLE/ActiveX.


V>>>>А что, сложно потратить пол-часа и запомнить, что означают символы UML? ))
L>>>Запоминать бессмысленные сущности? Ну, мне попадались такие люди. Полные бессмысленных сущностей.
V>>Это называет "эрудиция".
L>Некоторые и умение "ботать по фене" эрудицией называют.

Угу, тоже порой помогает понять собеседника.


L>Нет смысла запоминать изначально ущербную вымученную нотацию.

"Запоминать" её надо для писательства, а для читательства она интуитивно понятна и так.
Ну вот разве что запомнить отличие закрашенного ромбика начала связи от незакрашенного.
И то, в некоторых языках эти два вида связи неотличимы, т.е. эта инфа не принципиальна.

Я для писательства не помню, ес-но, но когда пришлось пару разпоупражняться — открыл описание нотации, открыл примеры, нарисовал за 15 мин.
Всё, вопрос исчерпан.


L>>>В UML есть две полезные вещи — Sequence Diagram (и то я уверен, что ее скопипастили туда откуда-то еще) и State Diagram.
V>>Разве ты не проходил их в ВУЗ-е?
L>Я собирался написать в "UML тулзах". И да, за брать на слабо иди в детский сад, ок?

Как-то странно ты скипнул часть вопроса:

Диаграммы состояний были изобретены за пол-века или более до UML.

Резьба по цитатам — это способ юления такой или как понимать?

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


V>>Кружочков, ромбиков, трапеций, стрелок и т.д.
V>>Твой пренебрежительный тон должен означать некое превосходство над этим всем?
L>Не некое, а подавляющее.

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


L>Это как с иностранным языком. Можно всю жизнь учить, что такое past perfect continuous, но так и не продвинуться дальше "читаю со словарем".

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

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

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

V>>Т.е., если бы эти утилиты позволяли, например, связать метод статической диаграммы с блок-схемой алгоритма или с параметризируемым шаблоном проектирования (из GoF или кучи еще библиотечных), позволял бы запускать это всё на симуляцию, задавая/играя параметрами алгоритмов — это был бы полноценный САПР.
V>>А так нет.
L>Это означает, что изначально идея подхода неправильная. Ее сделали исходя из примера других индустрий, где сначала — проект, а потом — реализация. Только вот мозгов не хватило понять, что в разработке софта технический проект — это собственно код программы на ЯП а реализация изначально автоматизирована компиляторами.

Забавная ахинея в стиле Шарикова. ))

Изачально ведь был автокод.
Это и был "технический проект"?

А одни из первых вменяемых ЯП — Фортран и Лисп, компилятор только первый.

В общем, коллега, еще не изобрели смайлика, чтобы выразить реакцию на подобные "окровения". ))


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

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

По моим наблюдениям, до глубины иерархии слоёв проектирования примерно 3 человек более-менее справляется.
Относительно алгоритмов — примерно до 7 шагов воспринимается на ура, а если больше — уже не помешает "подсказка" в том или ином виде.
Т.е., когда больше/глубже — начинаются сложности с восприятием.

Поэтому, графические представления никогда из программирования не уйдут.
И не важно, по какой нотации они выполнены.

Даже псевдокод, отбрасывающий детали — тоже разновидность нотации, ведь "это" живёт в независимом от проекта виде.

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

Всё вместе резко помогло.
Реальная практика.


L>Короче, для кода САПР — это IDE со всеми плюшками.

Современные IDE не отвечают определению САПР.
Это, скорее, продвинутые текстовые редакторы исходного кода вкупе с органайзером проектов.


V>>В этом смысле программистские недо-САПР типа Rational Rose и Together позволяли строить разве что, скажем, "проволочную модель", которая прозрачна и статична, не обладает параметрами или свойствами, не допускает симуляции работы, т.е. примерно бесполезна.
L>Не примерно, а не просто бесполезна, но еще и вредна.

В нашем деле вредна лишь категоричность и прочие проявления узости ума.


L>>>А что, дотком — это только веб? У меня для тебя новости.
V>>Бум и затем кризис доткомов (о котором периоде ты упоминал) — это бум и последующий кризис интернет-компаний, ес-но.
L>Иногда нужно и дальше википедии читать.
L>Интернет-компании были только вершиной айсберга. Тогда же почти все конторы обратили внимание на автоматизацию и появившиеся новые технологии, которые позволяли творить разнообразную дичь. Этот бум дал начало куче современных систем.

Увы для тебя, бум автоматизации не совпал с бумом доткомов — он начался примерно на 7 лет раньше.
И не был надутым пузырём — развитие ср-в автоматизации было поступательным.

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

Во времена бума доткомов много на что возложили надежд, не только на UML.
Основные надежды были:
— на быстрое продолжение развитие всемирной сети;
— на продолжение развития быстродействия компьютеров в духе 90-х;
— на продолжение развития интереса к интернету у населения со скоростью, показанной в период 95-2000-й год.

Все три пункта вошли в насыщение в начале 2000-х.
— cетка оказалась для населения дорогой и медленной.
— компьютеры резко замедлили рост быстродействия;
— даже чудовищные инвестиции в доткомы оказались не способны удовлетворить любопытство населения относительно новой технологии — т.е. развитие информационного и операционного наполнения Сети отставало от роста любопытства людей, что в итоге любопытство случилось, считай, однократным.

Но инвестиции в технологии донета не пропали даже с кризисом доткомов.
Пропали инвестиции в некоторые конкретные проекты — ну это такое...

Тут по класике надо понимать во что инвестируешь — в технологию, или в обезъянок, способных лишь использовать технологии, разработанные другими людьми.

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


V>>Если джава, плюсы, дельфи — то да.
V>>И то — плюсы и дельфи с натяжкой, бо в 90-е компонентный подход был более популярен, чем объектный с махровой иерархией наследования, тут только джава резвилась в полный рост, бгг...
L>Еще в начале 90-х на чистых сях писали ООП код. С таблицами виртуальных функций вручную, естественно. В начале нулевых я сам такой проект на плюсы переводил

Но без махровых ООП-иерархий наследования — читай внимательней.

Если ты про таблицу ф-ий драйверов ОС или плагинов в некоторой прикладной системе — это тот самый компонентный подход, т.е. абстракция одного уровня.
Туда же OLE/ActiveX.


V>>>>А что, сложно потратить пол-часа и запомнить, что означают символы UML? ))
L>>>Запоминать бессмысленные сущности? Ну, мне попадались такие люди. Полные бессмысленных сущностей.
V>>Это называет "эрудиция".
L>Некоторые и умение "ботать по фене" эрудицией называют.

Угу, тоже порой помогает понять собеседника.


L>Нет смысла запоминать изначально ущербную вымученную нотацию.

"Запоминать" её надо для писательства, а для читательства она интуитивно понятна и так.
Ну вот разве что запомнить отличие закрашенного ромбика начала связи от незакрашенного.
И то, в некоторых языках эти два вида связи неотличимы, т.е. эта инфа не принципиальна.

Я для писательства не помню, ес-но, но когда пришлось пару раз поупражняться — открыл описание нотации, открыл примеры, нарисовал за 15 мин.
Всё, вопрос исчерпан.


L>>>В UML есть две полезные вещи — Sequence Diagram (и то я уверен, что ее скопипастили туда откуда-то еще) и State Diagram.
V>>Разве ты не проходил их в ВУЗ-е?
L>Я собирался написать в "UML тулзах". И да, за брать на слабо иди в детский сад, ок?

Как-то странно ты скипнул часть вопроса:

Диаграммы состояний были изобретены за пол-века или более до UML.

Резьба по цитатам — это способ юления такой или как понимать?

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


V>>Кружочков, ромбиков, трапеций, стрелок и т.д.
V>>Твой пренебрежительный тон должен означать некое превосходство над этим всем?
L>Не некое, а подавляющее.

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


L>Это как с иностранным языком. Можно всю жизнь учить, что такое past perfect continuous, но так и не продвинуться дальше "читаю со словарем".

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

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