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

A>Я уже писал — ИС института (у нас в Универе на институты разбито, потом только на факультеты) — вся инфа по студентам, успеваемости, учебным планам и много чего еще вплоть до оборудования. Проект недавно начался, здесь как раз и нужно изучение предметной области в одном ключе с использованием одной нотации. Кое-где уже есть реализация, использующая эти диаграммы. Причем сам UML используется пока только % на 20 по той же причине — разработка только началась, дальщше его использование возрастет.

А чего бы просто базу в SQL сервере не сделать безо
всякого UML и дальше от этого плясать.

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

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

A>>Я уже писал — ИС института (у нас в Универе на институты разбито, потом только на факультеты) — вся инфа по студентам, успеваемости, учебным планам и много чего еще вплоть до оборудования. Проект недавно начался, здесь как раз и нужно изучение предметной области в одном ключе с использованием одной нотации. Кое-где уже есть реализация, использующая эти диаграммы. Причем сам UML используется пока только % на 20 по той же причине — разработка только началась, дальщше его использование возрастет.

A>А чего бы просто базу в SQL сервере не сделать безо
A>всякого UML и дальше от этого плясать.

браво, Анатоликс! Просто базу! :-"Просто базу" надо еще спроектировать исходя из определенных требований и анализа предметной области. "Плясать от базы" — это хорошо для тривиальных задач, но в серьезных системах это, простите, дилетантство. Такой подход "снизу вверх" не оправдает себя.

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

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

M.NET>>>Не правда. UML был придуман для краткого изложения мыслей. Если ты потом берёшься объяснять кому-то, что ему надо делать, то к этим диаграммам всё равно напишешь тонну голого текста, поясняющего что да как. Одной картинкой сыт не будешь
AS>>а вот енто уже зависит от умения грамотно составить диаграммы

M.NET>Всё на диаграмме не изобразишь. Пояснения всё равно нужны.
так вот именно что пояснения всеравно нужны, но это только пояснения, а основным источником информации являются диаграммы

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

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

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

A>UML — Унифицированный язык моделирования. Моделирования. То есть прежде всего он придуман для унифицированного представления предметной области, ее единого описания с различных точек зрения. Во многих задачах лучше подходит, чем тот же IDEF0.

A>Мишка тут писал про отовые прототипы... Без изучения предметной области этого сделать нельзя — здесь UML и пригодится.

A>Спецификации же можно писать и на простом языке — здесь я с ним согласен, хотя и не на все 100.

A>P.S. Блин, надо что-то делать с разницей во времени — все интересное пропускаю

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

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

N>браво, Анатоликс! Просто базу! :-"Просто базу" надо еще спроектировать исходя из определенных требований и анализа предметной области.

Да безусловно но UML то здесь зачем, SQL рулит.
Опять же зачем изобретать другой язык.

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

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

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


A>Почему дилетанство. У тебя есть хорошо спроектированная
A>база, если ты в нее данные закачаешь как предполагается
A>то задача будет практически уже сделана, т.к.
A>и ввод данных будет возможен единственным
A>образом и отчеты будет понятно как строить.

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

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

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

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

Я просто не понимаю почему надо писать в UML, я понимаю
что писать надо, надо проектировать, надо документировать но UML
здесь причем.

Вообщем я думаю что UML здесь используют с той же целью
как медики и аптекари используют латынь
1) Потому что так принято, так модно
2) Чтобы никому непонятно было и денег больше платили.

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


A>Я просто не понимаю почему надо писать в UML, я понимаю
A>что писать надо, надо проектировать, надо документировать но UML
A>здесь причем.

да UML просто притом, что в нем проще документировать взаимодействие компонент сложной системы.

A>Вообщем я думаю что UML здесь используют с той же целью
A>как медики и аптекари используют латынь
A>1) Потому что так принято, так модно
A>2) Чтобы никому непонятно было и денег больше платили.
так на UML кокраз и нужен чтоб всем понятно было! это УНИФИЦИРОВАННЫЙ язык, т.е. единый для все, чтоб всем было точно понятно что проектировщик имел ввиду, а не каждый трактовал слова проектировщика посвойму

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

A>Ну можно и так сказать, а можно сказать что UML это усложненный
A>подход. Зависит от точки зрения.

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

A>Вообщем я думаю что UML здесь используют с той же целью
A>как медики и аптекари используют латынь
A>1) Потому что так принято, так модно
A>2) Чтобы никому непонятно было и денег больше платили.
По-моему рецепты пишут на латыни для того, чтобы если ты вдруг поедешь в Гондурас, тебе там в аптеке по рецепту, выписаному в Росии, не выдадут, скажем, пурген вместо аспирина...

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

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

AS>да UML просто притом, что в нем проще документировать взаимодействие компонент сложной системы.
Дак чем легче то?

AS>единый для все, чтоб всем было точно понятно что проектировщик имел ввиду, а не AS>каждый трактовал слова проектировщика посвойму
Дак не может же быть чтобы проектировщик SQL не знал.
Как он тогда базу должен проектировать?

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

F>Если UML придуман именно для этих целей, то по-моему было бы удобнее использовать его, а не, скажем, просто английский язык (или русский), хотя бы потому, что в данном случае он (UML) лаконичнее и точнее.
SQL или С++ тоже абсолютно однозначен

F>По-моему рецепты пишут на латыни для того, чтобы если ты вдруг поедешь в Гондурас, тебе там в аптеке по рецепту, выписаному в Росии, не выдадут, скажем, пурген вместо аспирина...

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

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

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

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

A>Ну можно и так сказать, а можно сказать что UML это усложненный
A>подход. Зависит от точки зрения.

A>Я просто не понимаю почему надо писать в UML, я понимаю
A>что писать надо, надо проектировать, надо документировать но UML
A>здесь причем.

A>Вообщем я думаю что UML здесь используют с той же целью
A>как медики и аптекари используют латынь
A>1) Потому что так принято, так модно
A>2) Чтобы никому непонятно было и денег больше платили.

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

По-моему основной аргумент "противников" использованяи UML — то что можно прекрасно обойтись и без него. Так кто ж с этим спорит? Естественно, все можно описать и обычным языком. То, что UML не удобен — удобство это в большой степени вопрос привычки и если человек им никогда не пользовался, то он ему будет неудобен. Первое время.

Поэтому вопрос использования UML — это вопрос личных предпочтений, а на вкус и цвет, как известно...

ИМХО, преимущества использования UML проявяться только в большом проекте (уровня предприятия), в случае если большая часть участников с этим языком знакома.

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

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

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

AS>>да UML просто притом, что в нем проще документировать взаимодействие компонент сложной системы.
A>Дак чем легче то?

AS>>единый для все, чтоб всем было точно понятно что проектировщик имел ввиду, а не AS>каждый трактовал слова проектировщика посвойму
A>Дак не может же быть чтобы проектировщик SQL не знал.
A>Как он тогда базу должен проектировать?
для проектирования базы не нужно знать SQL, так же как для проектирования какой то системы не ныжно знать C++ или другой язык програмирования! проектировщик это не программер!!!

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

AS> для проектирования базы не нужно знать SQL, так же как для проектирования какой то системы не ныжно знать C++ или другой язык програмирования! проектировщик это не программер!!!

Не согласен: для проектировани базы необходимо и иметь
опыт работы для того чтобы запросы по этой базе выполнялись за
конечное время.

На счет языков: он не обязан знать конкретный, но программировать
должен уметь. Кроме того большой вопрос что лучше заставить
одного человека выучить C++ или 10 человек выучить UML.

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

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

F>>Если UML придуман именно для этих целей, то по-моему было бы удобнее использовать его, а не, скажем, просто английский язык (или русский), хотя бы потому, что в данном случае он (UML) лаконичнее и точнее.
A>SQL или С++ тоже абсолютно однозначен

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

F>>По-моему рецепты пишут на латыни для того, чтобы если ты вдруг поедешь в Гондурас, тебе там в аптеке по рецепту, выписаному в Росии, не выдадут, скажем, пурген вместо аспирина...

A>А почему латынь а не английский скажем, пользы то больше
A>было бы если бы всех медиков английскому выучили.

дык все исходя из удобств, и просто conventional...

зы: лет десять назад видел я и реализацию Тетриса на bat-скриптах (5-го ДОСа, кажеться). Впечатлило.Тоже пример, что МОЖНО топором Венеру Милосскую выстрогать, вопрос, сколько усилий на это уйдет.

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

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

AS>>:) для проектирования базы не нужно знать SQL, так же как для проектирования какой то системы не ныжно знать C++ или другой язык програмирования! проектировщик это не программер!!!

A>Не согласен: для проектировани базы необходимо и иметь
A>опыт работы для того чтобы запросы по этой базе выполнялись за
A>конечное время.

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

A>На счет языков: он не обязан знать конкретный, но программировать
A>должен уметь. Кроме того большой вопрос что лучше заставить
A>одного человека выучить C++ или 10 человек выучить UML.

знание UML не делает человека (хорошим) проектировщиком. Это лишь средство выражения чего-то в голове, причем, как уж сто раз тут повторили, введено для унификации средств выражения многих и каждого разработчика, попытка упорядочить этот Вавилон.

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

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

N>>браво, Анатоликс! Просто базу! :-"Просто базу" надо еще спроектировать исходя из определенных требований и анализа предметной области.

A>Да безусловно но UML то здесь зачем, SQL рулит.
A>Опять же зачем изобретать другой язык.

A>"Плясать от базы" — это хорошо для тривиальных задач, но в серьезных системах это, простите, дилетантство. Такой подход "снизу вверх" не оправдает себя.

A>Почему дилетанство. У тебя есть хорошо спроектированная
A>база, если ты в нее данные закачаешь как предполагается
A>то задача будет практически уже сделана, т.к.
A>и ввод данных будет возможен единственным
A>образом и отчеты будет понятно как строить.

Это все хорошо, но
1. Спроектировать даже относительно простую базу прямо в SQL довольно-таки затруднительно. Это примерно как построить что-либо, не рисуя чертежей, а сразу начав класть кирпичи. У меня опыт проектирования баз довольно-таки есть, особо хвастаться не буду, но даже в самых примитивных случаях (заказы — товары — элементы заказов) я сначала нарисую таблички хотя бы на бумаге. Даже если все сущности в системе на момент начала проектирования определены, их взаимоотношения не всегда очевидны. Кратность связей, возможность дубликатов, нуллов, и тому прочая практически всегда пересматриваются несколько раз для получения непротиворечивой модели. Стоимость таких экспериментов в ERWin, RR, или просто на бумаге, заметно ниже, чем при прямом проектировании в DDL. Хотя бы потому, что зараза сервер не даст нарушить констрэйнты даже на пустых таблицах, и модификации приходится выполнять в определенном порядке...

2. Как правило, в мало-мальски сложной системе (где количество сущностей переваливает за десяток) появляются отношения, плохо выразимые (а то и вообще невыразимые) средствами SQL. Например, наследование. Различные виды контроля ссылочной целостности (prohibit, cascade, NULL). И еще много чего.

3. Выражение таких отношений средствами SQL
а) не является взаимно однозначным (по тем же причинам, по которым эффективная декомпиляция C++ программ — гиблое занятие)
б) сильно зависит от используемого SQL сервера. Синтаксис расширений типа триггеров, хранимых процедур, view и прочих радостей жизни меняется так, что адекватный автоматический перенос модели с одной платформы на другую невозможен.
Подход "сначала выберем сервер, а потом начнем проектировать" я считаю вопиющим непрофессионализмом, т.к. выбор должен диктоваться требованиями, которые и определяются в процессе проектирования.

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

По этим причинам профессиональные разработчики никогда не проектируют базы данных в сервере базы данных. Сначала строится модель, причем как правило это либо UML, либо ER, либо лист бумаги, а затем по ней создаются таблички, индексы, и.т.п.

Разберетесь кто тут "А" ?

A>>Я уже писал — ИС института ...

A>А чего бы просто базу в SQL сервере не сделать безо
A>всякого UML и дальше от этого плясать.

Вопрос в лоб:

"А чего бы просто в UML не сделать безо
всякого SQL и дальше от этого плясать?"

Мы используем UML, ты SQL (знаешь, звучит как "мне нравится черный, а тебе памидоры" — потомучто разные вещи , ну и прекрасно. Хочу заметить, что вопрос состоял в том, надо ли изучать UML, а не использовать его.

Так что хотелось бы порекомендовать отвечать на вопрос "Почему НЕ надо ИЗУЧАТЬ UML" и поконкретнее... п то и мне теперь интересно стало Всегда думал, что любое знание не помешает, а вы тут такое развели!

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

F>Так что хотелось бы порекомендовать отвечать на вопрос "Почему НЕ надо ИЗУЧАТЬ UML" и поконкретнее... п то и мне теперь интересно стало Всегда думал, что любое знание не помешает, а вы тут такое развели!

Потому что на изучение вего требуется время, при этом
есть вещи которые мне хочется изучить больше чем UML.

Кроме того зазубрить синтаксис один раз и считать
что все сразу будет круто ото помоему глупо, а т.к.
использовать я его не собираюсь, я не буду его и учит
т.к. все равно забуду.

Убедить же меня что мне надо работать в UML
(не зубрить синтаксис а именно работать) меня могут
слудующие вещи:
1) Корпоративные правила(сейчас никто UML у нас не юзает, так что
аргумент "UML это стандарт" не катит. В моей среде это не стандарт)
2) Осознанная крутость UML(здесь мне никто доказать этого не может,
я вообще не из вредности тут со всеми спорю, и не из-за того
что не люблю UML. Просто мне хочется найти хотя бы один
аргумент за UML на который мне будет нечего возразить)

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

F>Разберетесь кто тут "А" ?

A>>>Я уже писал — ИС института ...

A>>А чего бы просто базу в SQL сервере не сделать безо
A>>всякого UML и дальше от этого плясать.

Я — это A, а A — это он