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

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

Учу читать:

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

В переводе на русский — начальство не уверено в том, что это им вообще надо, но выделить немного денег на эксперименты не проч.
Когда что-то действительно надо — там сценарии всегда другие.


L>и ожидаемо пролетела, ушлые дельцы загнали аналог Rational Rose как вундерфавлю.

Так "за обеды" или задорого?


V>>Взять Rational Rose, Together — это не полноценные САПР, т.к. не в состоянии автоматизировать создание конечного продукта.
V>>Это утилиты для архитекторов ПО.
L>А попытка генерации кода из оных — это для кого?

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

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

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

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

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

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


L>>>Были даже очень платные курсы по UML.
V>>UML более про ООП, при чём тут бум доткомов?
L>А что, дотком — это только веб? У меня для тебя новости.

Бум и затем кризис доткомов (о котором периоде ты упоминал) — это бум и последующий кризис интернет-компаний, ес-но.


L>>>Случалось, что не знающим, что означает ромбик в начале стрелочки, на собеседовании презрительно кидали "мы вам перезвоним".
V>>Тогдашние многие айтишники не проходили ООП в ВУЗ-ах, поэтому, осваивать эту парадигму самостоятельно было необходимо, ес-но.
L>Не надо всех по себе судить, ладно?

Я сужу не по себе, а по всем окружающим ровесникам, при том, что я был из "молодой" обоймы во второй половине 90-х — тот самый вчерашний студент.
ООП включили в программы ВУЗ-ов для 3-го курса моей специальности в год, когда я ВУЗ заканчивал.


L>ООП уже к концу 90-х был тем еще баяном.

Это смотря кто в каком языке работал.
Если джава, плюсы, дельфи — то да.
И то — плюсы и дельфи с натяжкой, бо в 90-е компонентный подход был более популярен, чем объектный с махровой иерархией наследования, тут только джава резвилась в полный рост, бгг...

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


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

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


L>В UML есть две полезные вещи — Sequence Diagram (и то я уверен, что ее скопипастили туда откуда-то еще) и State Diagram.

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

Разве ты не проходил их в ВУЗ-е?

UML — это, скорее, попытка разработать единую нотацию.
Но попытка вышла неудачной, т.к. нотации получились независимыми, поэтому САПР на основе ограничений UML априори не могут быть полноценными.
В общем, Гради Буч недоработал, увы.


L>Все остальное — просто набор квадратиков.

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


L>>>Я лично застал закономерное увядание оных в двух конторах.
V>>Оных чего?
L>Учу читать. Дорого (с)

Учись.

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

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

Учу читать:

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

В переводе на русский — начальство не уверено в том, что это им вообще надо, но выделить немного денег на эксперименты не проч.
Когда что-то действительно надо — там сценарии всегда другие.


L>и ожидаемо пролетела, ушлые дельцы загнали аналог Rational Rose как вундерфавлю.

Так "за обеды" или задорого?


V>>Взять Rational Rose, Together — это не полноценные САПР, т.к. не в состоянии автоматизировать создание конечного продукта.
V>>Это утилиты для архитекторов ПО.
L>А попытка генерации кода из оных — это для кого?

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

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

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

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

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

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


L>>>Были даже очень платные курсы по UML.
V>>UML более про ООП, при чём тут бум доткомов?
L>А что, дотком — это только веб? У меня для тебя новости.

Бум и затем кризис доткомов (о котором периоде ты упоминал) — это бум и последующий кризис интернет-компаний, ес-но.


L>>>Случалось, что не знающим, что означает ромбик в начале стрелочки, на собеседовании презрительно кидали "мы вам перезвоним".
V>>Тогдашние многие айтишники не проходили ООП в ВУЗ-ах, поэтому, осваивать эту парадигму самостоятельно было необходимо, ес-но.
L>Не надо всех по себе судить, ладно?

Я сужу не по себе, а по всем окружающим ровесникам, при том, что я был из "молодой" обоймы во второй половине 90-х — тот самый вчерашний студент.
ООП включили в программы ВУЗ-ов для 3-го курса моей специальности в год, когда я ВУЗ заканчивал.


L>ООП уже к концу 90-х был тем еще баяном.

Это смотря кто в каком языке работал.
Если джава, плюсы, дельфи — то да.
И то — плюсы и дельфи с натяжкой, бо в 90-е компонентный подход был более популярен, чем объектный с махровой иерархией наследования, тут только джава резвилась в полный рост, бгг...

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


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

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


L>В UML есть две полезные вещи — Sequence Diagram (и то я уверен, что ее скопипастили туда откуда-то еще) и State Diagram.

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

Разве ты не проходил их в ВУЗ-е?

UML — это, скорее, попытка разработать единую нотацию.
Но попытка вышла неудачной, т.к. нотации получились независимыми, поэтому САПР на основе ограничений UML априори не могут быть полноценными.
В общем, Гради Буч недоработал, увы.


L>Все остальное — просто набор квадратиков.

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


L>>>Я лично застал закономерное увядание оных в двух конторах.
V>>Оных чего?
L>Учу читать. Дорого (с)

Учись.