Форум Сообщества Аналитиков

×


Ситуация на рынке UML-средств(Прочитано 21586 раз)
Ситуация на рынке UML-средств : 13 Сентября 2007, 00:49:09
Цитировать
захотелось обратить внимание комьюнити на беспрецедентный кризис в области средств поддержки uml моделирования

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

В этом то главная проблема, стать ближе к заказчику (пользователю), а не создание полноценного метаязыка программирования.
Анатолий Дегтярёв ака tolldo

Ночь наиболее темна перед самым рассветом



Re: Ситуация на рынке UML-средств Ответ #1 : 13 Сентября 2007, 01:54:31
tolldo, ваша трактовка имеет смысл для аналитиков.

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

Попытки натянуть UML для бизнес-анализа и MDD возникли уже позже.

И CASE-средства, на мой взгляд, возникли именно как средство обуздания сложности манипулирования десятками диаграмм на бумаге инженером-проектировщиком, а также желанием превратить графику в модели, т.е. усилить их полезность.
« Последнее редактирование: 13 Сентября 2007, 01:57:57 от Денис "Майевтик" »



Re: Ситуация на рынке UML-средств Ответ #2 : 13 Сентября 2007, 08:52:55
Однако, насколько я помню, UML задумывался именно как средство облегчения коммуникации среди технических специалистов относительно устройства систем и проектных решений.
И CASE-средства, на мой взгляд, возникли именно как средство обуздания сложности манипулирования десятками диаграмм на бумаге инженером-проектировщиком, а также желанием превратить графику в модели, т.е. усилить их полезность.
Полностью согласен с Денисом, и категорические не согласен с Анатолием. Потребность возникновения case и в частности UML, как раз и была продиктована тем, что объектная парадигма и ООП к тому времени не имели хороших инструментов формализации, как например развитые графические нотации структурного подхода.



Re: Ситуация на рынке UML-средств Ответ #3 : 13 Сентября 2007, 12:21:22
2 Денис "Майевтик"
Цитировать
Однако, насколько я помню, UML задумывался именно как средство облегчения коммуникации среди технических специалистов относительно устройства систем и проектных решений.

2 Galogen
Цитировать
Полностью согласен с Денисом, и категорические не согласен с Анатолием. Потребность возникновения case и в частности UML, как раз и была продиктована тем, что объектная парадигма и ООП к тому времени не имели хороших инструментов формализации, как например развитые графические нотации структурного подхода.

IMHO, это спор про курицу и яйца. :) Что было раньше: первый компьютер или потребность в высокопроизводительных вычислениях?.. Я тоже кое-что помню и остаюсь на своей точке зрения. И если обсуждать это, то в другой теме.
« Последнее редактирование: 13 Сентября 2007, 12:36:52 от tolldo »
Анатолий Дегтярёв ака tolldo

Ночь наиболее темна перед самым рассветом



Re: Ситуация на рынке UML-средств Ответ #4 : 13 Сентября 2007, 12:41:50
2 Денис "Майевтик"
2 Galogen
IMHO, это спор про курицу и яйца. :) Что было раньше: первый компьютер или потребность в высокопроизводительных вычислениях?.. Я тоже кое-что помню и остаюсь на своей точке зрения. И если обсуждать это, то в другой теме.
Анатолий, я говорил про CASE-средства, поддерживающие UML. Не думаете же вы что книга Гради Буча "Объектно-ориентированный анализ и проектирование", например, в которой была изложена нотация, явившаяся предтечей UML, была написана для Заказчиков?



Re: Ситуация на рынке UML-средств Ответ #5 : 13 Сентября 2007, 13:19:56
2 Денис "Майевтик"

Цитировать
Не думаете же вы что книга Гради Буча "Объектно-ориентированный анализ и проектирование", например, в которой была изложена нотация, явившаяся предтечей UML, была написана для Заказчиков?

Ну да. DFD, ERD, STD; Йордан, Чен, Баркер, Константайн, Джексон,...

Вы представляете себе водителя первого автомобиля? Если книга адресована ему. То он кто, пользователь или технический специалист? Сравните тот автомобиль с современным. Обязан ли водитель современного автомобиля одновременно быть и техническим специалистом? Я об этом говорю. Компьютерные технологии еще так молоды. Мы находимся еще в самом начале Пути. :)
Анатолий Дегтярёв ака tolldo

Ночь наиболее темна перед самым рассветом



Re: Ситуация на рынке UML-средств Ответ #6 : 13 Сентября 2007, 13:32:21
IMHO, это спор про курицу и яйца. :) Что было раньше: первый компьютер или потребность в высокопроизводительных вычислениях?

В данном случае мы обсуждаем UML средства. Они возникли после того, как курицу съели. А яйцо уже стухло :-)
К тому, что сначала был создан язык с объектной парадигмой, к нему применяли структурные нотации. Плохо



Re: Ситуация на рынке UML-средств Ответ #7 : 14 Сентября 2007, 01:12:34
Птичку жалко  :(
Анатолий Дегтярёв ака tolldo

Ночь наиболее темна перед самым рассветом



Re: Ситуация на рынке UML-средств Ответ #8 : 22 Сентября 2007, 11:39:49
2 Денис "Майевтик"

Ну да. DFD, ERD, STD; Йордан, Чен, Баркер, Константайн, Джексон,...

Вы представляете себе водителя первого автомобиля? Если книга адресована ему. То он кто, пользователь или технический специалист? Сравните тот автомобиль с современным. Обязан ли водитель современного автомобиля одновременно быть и техническим специалистом? Я об этом говорю. Компьютерные технологии еще так молоды. Мы находимся еще в самом начале Пути. :)
Речь шла конкретно о книге Гради Буча "Объектно-ориентированный анализ и проектирование", в которой была изложена нотация, явившаяся предтечей UML, она точно была написана НЕ для Заказчиков.
Вы наверно не очень внимательно читали. Там все для улучшения жизни программистов. Прочтите.
 Картинки, например, "purrr purrr" прикольные =))) Интересно, кто Бучу помогал рисунки эти делать, они сразу помогают понять сущность вопроса.
« Последнее редактирование: 22 Сентября 2007, 11:42:44 от Sunshine »



Re: Ситуация на рынке UML-средств Ответ #9 : 23 Сентября 2007, 00:26:19
Уважаемая Sunshine! Вы совершенно правы, книги я читаю невнимательно, ничего уже не помню, когда, что и о чем читал.  :) И книга Г. Буча действительно написана для программистов. Вот только тема не об этом. Я говорю о принципах разработки и проектирования, лежащих в основе ООП и UML.

Когда я говорю о пользователе (заказчике), то имею ввиду, например, бухгалтера, которому нужно посчитать какой-нибудь баланс и распечатать отчет, или инженера, которому нужно рассчитать, скажем, траекторию полета ракеты. Пользователь (заказчик) он работает со своей предметной областью. Разрабатывая систему, мы моделируем предметную область заказчика.

Но есть и другая модель, модель самой системы, ее реализация на различных уровнях абстракции в конкретном железе и системных программных средах. Г. Буч называет построение такой модели структурным анализом. Цитирую классика.
Цитировать
Вторая альтернатива классической технике объектно-ориентированного анализа использует структурный анализ как основу для объектно-ориентированного проектирования. Такой подход привлекателен потому, что много аналитиков применяют этот подход и имеется большое число программных CASE-средств, поддерживающих автоматизацию этих методов. Нам лично не нравится использовать структурный анализ как основу для объектно-ориентированного проектирования, но для некоторых организаций такой прагматический подход не имеет альтернативы.
После проведения структурного анализа мы уже имеем модель системы, описанную диаграммами потоков данных и другими продуктами структурного анализа.
Цитировать
Необходимо отметить, что принципы структурного проектирования, которое, естественно, следует за структурным анализом, полностью ортогональны принципам объектно-ориентированного проектирования. Наш опыт показывает, что использование структурного анализа в процессе объектно-ориентированного проектирования часто приводит к полному провалу, если разработчик не способен сопротивляться желанию свалиться в структурную пропасть... Поэтому мы предпочитаем объектно-ориентированный анализ и анализ проблемной области как подготовительный этап для объектно-ориентированного проектирования. При этом уменьшается риск замусорить проект элементами алгоритмического анализа.
Цитировать
Если же по каким-либо уважительным причинам [Политические и исторические причины в качестве уважительных не принимаются] приходится взять за основу структурный анализ, прекратите строить диаграммы, как только они начинают смахивать на проект программы, а не на модель предметной области. Помните, что материалы проектирования, такие, как диаграммы потоков данных, это не конечный продукт, а инструмент разработчиков. Обычно строятся диаграммы, а затем разрабатываются механизмы, обеспечивающие необходимое поведение системы, то есть сам акт проектирования видоизменяет начальную модель. Поддержание соответствия модели и развивающегося проекта - дело трудное, и, честно говоря, бесполезное. Имеет смысл сохранять только продукт структурного анализа высокого уровня абстракции. Он отражает существенные черты и достаточно независим от проекта системы.
Анатолий Дегтярёв ака tolldo

Ночь наиболее темна перед самым рассветом



Re: Ситуация на рынке UML-средств Ответ #10 : 23 Сентября 2007, 00:50:38
...Продолжение

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

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

В этом то главная проблема, стать ближе к заказчику (пользователю), а не создание полноценного метаязыка программирования.
Анатолий Дегтярёв ака tolldo

Ночь наиболее темна перед самым рассветом



Re: Ситуация на рынке UML-средств Ответ #11 : 23 Сентября 2007, 19:55:42
Здесь явно масонский заговор :)



Re: Ситуация на рынке UML-средств Ответ #12 : 23 Сентября 2007, 22:38:43
Как страшно жить  :)
Анатолий Дегтярёв ака tolldo

Ночь наиболее темна перед самым рассветом



Re: Ситуация на рынке UML-средств Ответ #13 : 24 Сентября 2007, 11:37:25
2 tolldo

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



Re: Ситуация на рынке UML-средств Ответ #14 : 24 Сентября 2007, 14:38:08
2 tolldo

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

IMHO, без существенного вовлечения пользователя (заказчика) в процесс разработки (прямого или косвенного) сложно рассчитывать на получение действительно качественного, нужного продукта. Тут и появляется фигура аналитика  :), который для пользователя (в его понимании) является программистом, а для программиста - заказчиком (формализует представления заказчика о продукте).

Но в принципе, подготовленный заказчик может все это проделать и сам. И швец, и жнец, и на дуде игрец.  :)
Анатолий Дегтярёв ака tolldo

Ночь наиболее темна перед самым рассветом




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19