Эта дискуссия на google groups: http://groups.google.com/group/fido7.su.dbms.case/browse_thread/thread/5e0e55802cd4bf27 fido7.su.dbms.case ------------------ Автор: *Slava Pogrebnyak ). Прямо священная война какая-то получатеся между структурным и ОО проектированием. Для руководителей модели UML кажутся нагляднее, но возможно в простоте кроется что-то нехорошее ? А что думают участники эхи по этому поводу (извиняюсь, если провоцирую перепалку между апологетами этих подходов, в этом случае прошу отвечать нетмайлом или (лучше) емайлом). Спасибо заранее. С уважением, Вячеслав. e-mail: p...@infopac.ru Автор: *"Serguei Tarassov" Дата: *Thu, 17 May 2001 15:01:14 +0000 (UTC)* Местное время: *Чт. 17 май 2001 16:01* Тема: *Re: моделирование бизнес-процессов* Доброго дня! Насколько я понял из описаний UML, в розе можно сделать модель "как есть". А вот оптимизировать (модель "как будет") ее без структурного системного анализа вряд ли удастся. Если неправ, ткните на примеры. > Здравствуйте, уважаемый All ! > Крупное промышленное предприятие, в котором я возглавляю отдел, поручило мне > заняться моделированием бизнес-процессов. Опыт (какой-никакой) есть в > структурном моделировании (bpwin). Сейчас начал строить процессы в rose и думаю > - не иду ли я в неправильном направлении ? Перечитал много статей (например из > "Директор информационной службы" www.osp.ru ). Прямо священная война какая-то > получатеся между структурным и ОО проектированием. Для руководителей модели UML > кажутся нагляднее, но возможно в простоте кроется что-то нехорошее ? > А что думают участники эхи по этому поводу (извиняюсь, если провоцирую > перепалку между апологетами этих подходов, в этом случае прошу отвечать > нетмайлом или (лучше) емайлом). > Спасибо заранее. > С уважением, Вячеслав. e-mail: p...@infopac.ru -- с уважением, Сергей Тарасов http://www.arbinada.com mailto:temp...@arbinada.com Автор: *"Lev Yunak" * Дата: *Fri, 18 May 2001 08:21:20 +0000 (UTC)* Местное время: *Пт. 18 май 2001 09:21* Тема: *Re: моделирование бизнес-процессов* Serguei Tarassov сообщил в новостях следующее: > Насколько я понял из описаний UML, в розе можно сделать модель "как есть". А > вот оптимизировать (модель "как будет") ее без структурного системного > анализа вряд ли удастся. Сложно, но можно. А вообще UML не для анализа "как есть". Она для проектирования сразу как надо. Точнее, термин "как есть", существующий в SADT для UML нельзя применить. Это другая технология. Автор: *"Serguei Tarassov" * Дата: *Fri, 18 May 2001 15:10:59 +0000 (UTC)* Местное время: *Пт. 18 май 2001 16:10* Тема: *Re: моделирование бизнес-процессов* Доброго дня! "Lev Yunak" wrote in message news > Serguei Tarassov сообщил в новостях следующее: > > Насколько я понял из описаний UML, в розе можно сделать модель "как есть". А > > вот оптимизировать (модель "как будет") ее без структурного системного > > анализа вряд ли удастся. > Сложно, но можно. А вообще UML не для анализа "как есть". Она для > проектирования сразу как надо. > Точнее, термин "как есть", существующий в SADT для UML нельзя применить. Это > другая технология. А как надо? ;-) Для этого и придуман системный подход и SADT(IDEF0), чтобы понять, как надо. Поясню мысль. Предположим, организовывается некий новый процесс. UML оперирует объектами, которых на данном этапе еще нет. В системном же подходе сначала формулируются цели, а уже потом подбираются объекты для их достижения. Так что я склонен рассматривать UML как некий язык чертежей и эскизов деталей для реализации, не объясняющих, а собственно, на кой ляд эти детали нужны. -- с уважением, Сергей Тарасов http://www.arbinada.com mailto:temp...@arbinada.com Автор: *"Lev Yunak" * Дата: *Mon, 21 May 2001 05:30:20 +0000 (UTC)* Местное время: *Пн. 21 май 2001 06:30* Тема: *Re: моделирование бизнес-процессов* Serguei Tarassov сообщил в новостях следующее: > > > Насколько я понял из описаний UML, в розе можно сделать модель "как > > > есть". А вот оптимизировать (модель "как будет") ее без структурного системного > > > анализа вряд ли удастся. > > Сложно, но можно. А вообще UML не для анализа "как есть". Она для > > проектирования сразу как надо. > > Точнее, термин "как есть", существующий в SADT для UML нельзя применить. > > Это другая технология. > А как надо? ;-) > Для этого и придуман системный подход и SADT(IDEF0), чтобы понять, как надо. SADT позволяет построив модель системы "как есть" легко увидеть все недочеты. То есть, на момент анализа еще неизвестно "что не так" > Поясню мысль. Предположим, организовывается некий новый процесс. > UML оперирует объектами, которых на данном этапе еще нет. Правильно. Анализ и проектирование системы с нуля. > В системном же подходе сначала формулируются цели, а уже потом подбираются объекты для их > достижения. Неправильно. Понятие цели в SADT несколько другое - там есть "цель анализа". Цель функционирования системы известна и незыблема. > Так что я склонен рассматривать UML как некий язык чертежей и эскизов > деталей для реализации, не объясняющих, а собственно, на кой ляд эти детали > нужны. Ммм. Небольшой совет: почитайте еще раз про UML, особенно про use case. Только забыв на время про SADT. Это разные подходы и экстраполировать их друг на друга не стоит. Автор: *"Serguei Tarassov" * Дата: *Mon, 21 May 2001 14:27:09 +0000 (UTC)* Местное время: *Пн. 21 май 2001 15:27* Тема: *Re: моделирование бизнес-процессов* Доброго дня! "Lev Yunak" wrote in message news: > SADT позволяет построив модель системы "как есть" легко увидеть все недочеты. > То есть, на момент анализа еще неизвестно "что не так" А модель "как надо" не позволяет построить, что-ли? ;-) > > Поясню мысль. Предположим, организовывается некий новый процесс. > > UML оперирует объектами, которых на данном этапе еще нет. > Правильно. Анализ и проектирование системы с нуля. Так а где объекты-то, спрашиваю? ;-) Потом ведь появятся, когда станет ясно, что же действительно хотим сделать и с какими параметрами. > > В системном же > > подходе сначала формулируются цели, а уже потом подбираются объекты для их > > достижения. > Неправильно. Понятие цели в SADT несколько другое - там есть "цель анализа". Что-что? Цель анализа? А каким образом она может отразится на модели "как есть"? > Цель функционирования системы известна и незыблема. Вот-вот. Это уже ближе к истине. > Ммм. Небольшой совет: почитайте еще раз про UML, особенно про use case. > Только забыв на время про SADT. Это разные подходы и экстраполировать их друг на > друга не стоит. Я не экстраполирую, а просто утверждаю примерно следующее: прецеденты в UML ни что иное, как "листья" в иерархической диаграмме SADT. Вы когда отдыхать едете тоже с прецедентов типа "регистрация билета" начинаете или составляете план, вроде: чтобы поехать отдохнуть надо выбрать место, узнать про наличие гостиницы и забронировать номер, решить на чем добираться и купить билеты и т.д. по древу вглубь? -- с уважением, Сергей Тарасов http://www.arbinada.com mailto:temp...@arbinada.com Автор: *Alex Kulikov * Дата: *Sun, 20 May 2001 16:43:47 +0400* Местное время: *Вс. 20 май 2001 13:43* Тема: *моделирование бизнес-процессов* Hello Slava! 16 мая 2001, Slava Pogrebnyak пишет к All: SP> Прямо священная война какая-то получатеся между структурным и ОО SP> проектированием. Для руководителей модели UML кажутся нагляднее, но SP> возможно в простоте кроется что-то нехорошее ? Хм, UML имно вещь более моднопеpспективная так сказать. SP> А что думают участники эхи по этому поводу А думают что в SU.OOP (ноpмальная эха ксети) ты найдешь гоpаздо больше на волнующую тебя сейчас тему, здесь имно это только кpаем захватывается. Автор: *"Lev Yunak" * Дата: *Tue, 22 May 2001 06:40:56 +0000 (UTC)* Местное время: *Вт. 22 май 2001 07:40* Тема: *Re: моделирование бизнес-процессов* Serguei Tarassov сообщил в новостях следующее: > > > Поясню мысль. Предположим, организовывается некий новый процесс. > > > UML оперирует объектами, которых на данном этапе еще нет. > > Правильно. Анализ и проектирование системы с нуля. > Так а где объекты-то, спрашиваю? ;-) Они есть в мозгу у заказчика. Он в общих чертах знает что он хочет. Задача аналитика спроектировать новую систему или систему нового поколения. Есть другая ситация: есть некая система и менеджер этой системы чевствует, что что-то не так. То ли слишком много разных бесполезных бумажек подписывает, то ли народ носится как угорелый а доходы падают. Вот тут приходит аналитик с IDEF0 бланками и они на пару рисуют модель "как есть". И походу они видят все недочеты сущестсвующей системы, которые раньше разглядеть без анализа невозможно. Заметь, что IDEF0 довольно жесткая диаграмма. Никаких волностей. И это правильно. Это помогает четче проанализировать существующую систему. > > Неправильно. Понятие цели в SADT несколько другое - там есть "цель анализа". > Что-что? Цель анализа? А каким образом она может отразится на модели "как есть"? Кардинально. На первом листке IDEF0 ПЕРЕД началом анализа надо заполнить две строчки Цель и Точка зрения. > > Ммм. Небольшой совет: почитайте еще раз про UML, особенно про use case. > > Только забыв на время про SADT. Это разные подходы и экстраполировать их друг на > > друга не стоит. > Я не экстраполирую, а просто утверждаю примерно следующее: прецеденты в UML > ни что иное, как "листья" в иерархической диаграмме SADT. Вот уже скрещиваешь :) Найди определения прецедента UML и функции IDEF0 и сравни. Автор: *"Serguei Tarassov" * Дата: *Tue, 22 May 2001 11:09:54 +0000 (UTC)* Местное время: *Вт. 22 май 2001 12:09* Тема: *Re: моделирование бизнес-процессов* Доброго дня! "Lev Yunak" wrote in message news: > > Так а где объекты-то, спрашиваю? ;-) > Они есть в мозгу у заказчика. Он в общих чертах знает что он хочет. > Задача аналитика спроектировать новую систему или систему нового поколения. Да нет их еще в мозгу, если это не калька с образца. Вот когда функции детализируются, тогда и станет ясно, какие объекты можно применить для их реализации. > Заметь, что IDEF0 довольно жесткая диаграмма. Никаких волностей. И это > правильно. Это помогает четче проанализировать существующую систему. Разумеется. Но я не понял, хочешь ли ты противопоставить это диаграммам прецедентов, и в таком случае они не являются жесткими и не помогают проанализировать ситуацию? > > Что-что? Цель анализа? А каким образом она может отразится на модели "как есть"? > Кардинально. > На первом листке IDEF0 ПЕРЕД началом анализа надо заполнить две строчки > Цель и Точка зрения. Ты ошибаешься, это не цель анализа, а Цель системы с данной Точки зрения. > > Я не экстраполирую, а просто утверждаю примерно следующее: прецеденты в UML > > ни что иное, как "листья" в иерархической диаграмме SADT. > Вот уже скрещиваешь :) > Найди определения прецедента UML и функции IDEF0 и сравни. Да ради бога. Вот хотя бы тот же документ с "Интерфейса". Прецедент - это типичное взаимодействия пользователя с системой, которое при этом: - описывает видимую пользователем функцию, - может представлять различные уровни детализации, - обеспечивает достижение конкретной цели, важной для пользователя. И ты будешь продолжать утверждать, что это не есть листики в нижних ветвях SADT-диаграммы? ;-) -- с уважением, Сергей Тарасов http://www.arbinada.com mailto:temp...@arbinada.com Автор: *"Lev Yunak" * Дата: *Wed, 23 May 2001 09:19:44 +0000 (UTC)* Местное время: *Ср. 23 май 2001 10:19* Тема: *Re: моделирование бизнес-процессов* Serguei Tarassov сообщил в новостях следующее: > > > Что-что? Цель анализа? А каким образом она может отразится на модели "как есть"? > > Кардинально. > > На первом листке IDEF0 ПЕРЕД началом анализа надо заполнить две строчки > > Цель и Точка зрения. > Ты ошибаешься, это не цель анализа, а Цель системы с данной Точки зрения. Читаем доку... > > Найди определения прецедента UML и функции IDEF0 и сравни. > Да ради бога. Вот хотя бы тот же документ с "Интерфейса". > Прецедент - это типичное взаимодействия пользователя с системой, которое при этом: > - описывает видимую пользователем функцию, > - может представлять различные уровни детализации, > - обеспечивает достижение конкретной цели, важной для пользователя. > И ты будешь продолжать утверждать, что это не есть листики в нижних ветвях SADT-диаграммы? ;-) Для полноты картины приведи и определение функции в IDEF0. Автор: *"Serguei Tarassov" * Дата: *Fri, 25 May 2001 12:18:01 +0000 (UTC)* Местное время: *Пт. 25 май 2001 13:18* Тема: *Re: моделирование бизнес-процессов* Доброго дня! "Lev Yunak" wrote in message news: > Serguei Tarassov сообщил в новостях следующее: > > > > Что-что? Цель анализа? А каким образом она может отразится на модели "как есть"? > > > Кардинально. > > > На первом листке IDEF0 ПЕРЕД началом анализа надо заполнить две строчки > > > Цель и Точка зрения. > > Ты ошибаешься, это не цель анализа, а Цель системы с данной Точки зрения. > Читаем доку... Вот только не надо стрелки переключать. Та цель, которую ты имеешь в виду влияет на сам процесс моделирования и его результат в виде масштаба (глубины) модели. Но к рассматриваемой аналитиком системе она отношения не имеет - это его, аналитика, цель. Теперь посмотри нитку назад, а я напомню, что мы говорили на тему: Я: В системном же подходе сначала формулируются цели, а уже потом подбираются объекты для их достижения. Ты: Неправильно. Понятие цели в SADT несколько другое - там есть "цель анализа". Хорошо, давай будем говорить о функции системы, а не о цели, тем более, что формально ты прав, хотя понятие главной цели и главной функци в системе, как правило, совпадают (Цель грузового автомобиля: перевозка грузов, а его главная функция - перевезти груз). Тогда я повторю посылку: "При синтезе в системном подходе сначала формулируются функции (чтобы достичь цели) системы, а уже потом под эти функции подбираются объекты." Эти функции, точнее цели которых они призваны достигать, ортогональны целям аналитика (моделирования), на которые ты почему-то перешел. > > Прецедент - это типичное взаимодействия пользователя с системой, которое > >при этом: > > - описывает видимую пользователем функцию, > > - может представлять различные уровни детализации, > > - обеспечивает достижение конкретной цели, важной для пользователя. > > И ты будешь продолжать утверждать, что это не есть листики в нижних ветвях > > SADT-диаграммы? ;-) > Для полноты картины приведи и определение функции в IDEF0. В SADT(IDEF0) определение функции ничем не отличается от общепринятого. Если модель функциональная (а мы говорим о ней), то это синоним понятия "деятельность" и в конечном итоге функции, выполняемой данной подсистемой в иерархии. Я думал, ты в курсе... Хотя в тех же документах IDEF0 даже не удосужились явно привести хотя бы общепринятое определение. -- с уважением, Сергей Тарасов http://www.arbinada.com mailto:temp...@arbinada.com Автор: *"Lev Yunak" * Дата: *Tue, 29 May 2001 10:14:29 +0000 (UTC)* Местное время: *Вт. 29 май 2001 11:14* Тема: *Re: моделирование бизнес-процессов* Serguei Tarassov сообщил в новостях следующее: Рад, что наконец мы начали читать, что пишет другой :) > "При синтезе в системном подходе сначала формулируются функции (чтобы > достичь цели) системы, а уже потом под эти функции подбираются объекты." Системный подход это что? Структурный анализ или ОО анализ? Чувствую, что имелся ввиду структурный. Подбор объектов к функции - это наверное IDEF1X, а это еще больше расходится с UML, так как что-то похожее в нем это Class diagram - что гораздо шире проектирования структуры БД. Согласись - не стыкуются эти две метода анализа. Разные они, как яблоко и груша. Оба вкусные, в обоих встречаются червяки, но нельзя сказать что один лучше другого. > > > Прецедент - это типичное взаимодействия пользователя с системой, которое > > >при этом: > > > - описывает видимую пользователем функцию, > > > - может представлять различные уровни детализации, > > > - обеспечивает достижение конкретной цели, важной для пользователя. > > > И ты будешь продолжать утверждать, что это не есть листики в нижних ветвях > > > SADT-диаграммы? ;-) > > Для полноты картины приведи и определение функции в IDEF0. > В SADT(IDEF0) определение функции ничем не отличается от общепринятого. Если > модель функциональная (а мы говорим о ней), то это синоним понятия > "деятельность" и в конечном итоге функции, выполняемой данной подсистемой в иерархии. > Я думал, ты в курсе... Хотя в тех же документах IDEF0 даже не удосужились > явно привести хотя бы общепринятое определение. Что определения нет я знал, но я думал ты пойдешь дальше... :) Идем дальше. У функции в IDEF0 есть обвязка ввиде - ICOM У прецедента из UML этого нет. Но есть другое - субъекты (отличается от Control!), связи с другими функциями в том числе связи extend и наследование, которых нет в IDEF0 То есть можно сказать, что даже если прецедент = функция, о полном эквиваленте этих понятий речь не идет. Автор: *"Vladimir Pavlikov" * Дата: *Tue, 29 May 2001 11:19:48 +0000 (UTC)* Местное время: *Вт. 29 май 2001 12:19* Тема: *Re: моделирование бизнес-процессов* Hello! "Lev Yunak" wrote: > > "При синтезе в системном подходе сначала формулируются функции (чтобы > > достичь цели) системы, а уже потом под эти функции подбираются объекты." > Системный подход это что? Структурный анализ или ОО анализ? Ключевым словом во фразе является не системный подход, а синтез - антипод анализа :) -- Владимир Павликов. Автор: *"Serguei Tarassov" * Дата: *Tue, 29 May 2001 12:45:08 +0000 (UTC)* Местное время: *Вт. 29 май 2001 13:45* Тема: *Re: моделирование бизнес-процессов* Доброго дня! Кстати, Владимир, весьма интересно и твое мнение по этой нитке ;-) в частности по тезису "Use Case являются листьями (нижними уровнями) в SADT-диаграммах". Кстати, еще один плюсик в сторону IDEF - наличие достаточно четкой методологии (типа садись и работай), которой не видно для Use Case. В общем-то это понятно, если вспомнить, что сам UML рос из программирования и имел целью унифицированно описать именно программную систему. 2 All: А вот также интересно было бы взять небольшой примерчик, сделать 2 описания (на UML и IDEF0) и сравнить семантическую ценность этих моделей 1) для заказчика 2) для архитектора ПО. "Vladimir Pavlikov" wrote in message news: > Hello! "Lev Yunak" wrote: > > > "При синтезе в системном подходе сначала формулируются функции (чтобы > > > достичь цели) системы, а уже потом под эти функции подбираются объекты." > > Системный подход это что? Структурный анализ или ОО анализ? > Ключевым словом во фразе является не системный подход, а синтез - антипод > анализа :) > -- > Владимир Павликов. > Отправлено через сервер Talk.Ru - http://www.talk.ru -- с уважением, Сергей Тарасов http://www.arbinada.com mailto:temp...@arbinada.com Автор: *"Vladimir Pavlikov" * Дата: *Tue, 29 May 2001 15:31:53 +0000 (UTC)* Местное время: *Вт. 29 май 2001 16:31* Тема: *Re: моделирование бизнес-процессов* Hello! "Serguei Tarassov" wrote: > Кстати, Владимир, весьма интересно и твое мнение по этой нитке ;-) в Не, оно даже мне неинтересно :) Поскольку заключается в том, что UML является "инструментом" рисования :( > Кстати, еще один плюсик в сторону IDEF - наличие достаточно четкой > методологии (типа садись и работай), которой не видно для Use Case. В Именно. А в uml я не вижу ни методологии, ни языка... Прошу прощения за ворчание, но пользоваться приходится, жаль впустую потраченного времени. > общем-то это понятно, если вспомнить, что сам UML рос из программирования и > имел целью унифицированно описать именно программную систему. Угу. Как-то вдвоем делали диаграмму переходов для одного класса. В смысле - не вдвоем, а двое, по-отдельности. А дальше - игра : найди хоть пару общего. Получилось показательно унифицированно :) -- Владимир Павликов. Отправлено через сервер Talk.Ru - http://www.talk.ru Автор: *"Lev Yunak" * Дата: *Wed, 30 May 2001 07:00:30 +0000 (UTC)* Местное время: *Ср. 30 май 2001 08:00* Тема: *Re: моделирование бизнес-процессов* Vladimir Pavlikov сообщил в новостях следующее: > > > "При синтезе в системном подходе сначала формулируются функции (чтобы > > > достичь цели) системы, а уже потом под эти функции подбираются объекты." > > Системный подход это что? Структурный анализ или ОО анализ? > Ключевым словом во фразе является не системный подход, а синтез - антипод анализа :) Наверное старый стал. Поясните вашу фразу, пожалуйста. Автор: *"Lev Yunak" * Дата: *Wed, 30 May 2001 07:16:46 +0000 (UTC)* Местное время: *Ср. 30 май 2001 08:16* Тема: *Re: моделирование бизнес-процессов* Vladimir Pavlikov сообщил в новостях следующее: > > Кстати, Владимир, весьма интересно и твое мнение по этой нитке ;-) в > Не, оно даже мне неинтересно :) Поскольку заключается в том, что UML > является "инструментом" рисования :( А мы не только рисуем :) Мы структуры бд из модели делаем и описание рабочих мест, которые генерят роли в бд. Осталось формы ввода там специфицировать. Но есть сложности в плане, чтобы это было визуально удобно и информативно для автогенерации. Через Розу модель открытая для манипуляций (COM, или rose script). В IDEF я такого не видел. > > Кстати, еще один плюсик в сторону IDEF - наличие достаточно четкой > > методологии (типа садись и работай), которой не видно для Use Case. Тут баланс должен быть между ограничениями методологии и свободой аналитика. Многие "свободы" в uml могут не использоватся, но они есть. И это радует, хотя на первом этапе это отпугивает - не знаешь в какую сторону стрелку направить :) > А в uml я не вижу ни методологии, ни языка... ???? Поясните плиз. > > общем-то это понятно, если вспомнить, что сам UML рос из программирования и > > имел целью унифицированно описать именно программную систему. > Угу. Как-то вдвоем делали диаграмму переходов для одного класса. В смысле - > не вдвоем, а двое, по-отдельности. А дальше - игра : найди хоть пару общего. > Получилось показательно унифицированно :) Значит у вас не та подготовка или разная исходная информация или разные цели. Если мы с моим босом начнем рисовать одно и тоже - получится одинаково :) Названия элементов только разные будут. Автор: *"Vladimir Pavlikov" * Дата: *Wed, 30 May 2001 11:10:07 +0000 (UTC)* Местное время: *Ср. 30 май 2001 12:10* Тема: *Re: моделирование бизнес-процессов* Hello! "Lev Yunak" wrote: > > > > "При синтезе в системном подходе сначала формулируются функции (чтобы > > > > достичь цели) системы, а уже потом под эти функции подбираются объекты." > > > Системный подход это что? Структурный анализ или ОО анализ? > > Ключевым словом во фразе является не системный подход, а синтез - антипод > > анализа :) > Наверное старый стал. Поясните вашу фразу, пожалуйста. В исходной фразе речь идет не о самом СП, а о той его части, которая называется синтезом. Она оставляет открытым вопрос о том, является ли СП _только_ синтезом, но то, что СП анализом является не может, следует однозначно. Моя фраза указывает на это явно, но и она осталось не понятой :( -- Владимир Павликов. Отправлено через сервер Talk.Ru - http://www.talk.ru Автор: *"Vladimir Pavlikov" * Дата: *Wed, 30 May 2001 11:40:47 +0000 (UTC)* Местное время: *Ср. 30 май 2001 12:40* Тема: *Re: моделирование бизнес-процессов* Hello! "Lev Yunak" wrote: > > А в uml я не вижу ни методологии, ни языка... > ???? Поясните плиз. Что именно пояснить? Стандартизацию визуальных элементов вижу, язык и методологию - нет. RUP - это уже не вполне uml, да и он не вполне методология. Это, скорее, пояснять (мне и другим) стоит тому, кто видит. > > Как-то вдвоем делали диаграмму переходов для одного класса. В смысле - > > не вдвоем, а двое, по-отдельности. А дальше - игра : найди хоть пару общего. > > Получилось показательно унифицированно :) > Значит у вас не та подготовка или разная исходная информация или разные > цели. Это означает лишь, что понятия состояния [и их связей] трактуемы шире, чем хотелось бы. -- Владимир Павликов. Отправлено через сервер Talk.Ru - http://www.talk.ru Автор: *"Lev Yunak" * Дата: *Thu, 31 May 2001 05:01:21 +0000 (UTC)* Местное время: *Чт. 31 май 2001 06:01* Тема: *Re: моделирование бизнес-процессов* Vladimir Pavlikov сообщил в новостях следующее: > > > А в uml я не вижу ни методологии, ни языка... > > ???? Поясните плиз. > Что именно пояснить? Стандартизацию визуальных элементов вижу, язык > и методологию - нет. RUP - это уже не вполне uml, да и он не вполне > методология. Это, скорее, пояснять (мне и другим) стоит тому, кто видит. Тогда что по вашему методология? И что такое язык применительно для анализа и дизайна? Разве буква L в аббревиатуре UML не сокращение слова язык? Автор: *"Vladimir Pavlikov" * Дата: *Thu, 31 May 2001 11:08:59 +0000 (UTC)* Местное время: *Чт. 31 май 2001 12:08* Тема: *Re: моделирование бизнес-процессов* Hello! "Lev Yunak" wrote: > Тогда что по вашему методология? > И что такое язык применительно для анализа и дизайна? Разве буква L в > аббревиатуре UML > не сокращение слова язык? Язык - это то, что состоит из предложений (statements), а те, в свою очередь, из ["ключевых" и прочих] слов (operators, operations, expre- ssions, values etc). Сами диаграммы, и внешний вид и размещение, связи и пр. хранятся же тулами в каком-то виде. Но - каждый в своем, ибо uml- языка нет. Несмотря на сокращение в аббревиатуре. Что до методологии - я приводил пример. Если бы методология существовала то, при следовании ей, одна и та же работа двух разных людей давала бы (при реализации одного и того же) практически одинаковый результат. Я уже писал, что несогласные имеют полное право показать наличие языка ли, методологии ли - сами. Пока я вижу лишь вопросы, т.е. перенос разговора на более абстрактный уровень. Есть ли смысл? - не уверен. -- Владимир Павликов. Отправлено через сервер Talk.Ru - http://www.talk.ru Автор: *"Lev Yunak" * Дата: *Thu, 31 May 2001 12:01:58 +0000 (UTC)* Местное время: *Чт. 31 май 2001 13:01* Тема: *Re: моделирование бизнес-процессов* Vladimir Pavlikov сообщил в новостях следующее: > > Тогда что по вашему методология? > > И что такое язык применительно для анализа и дизайна? Разве буква L в > > аббревиатуре UML > > не сокращение слова язык? > Язык - это то, что состоит из предложений (statements), а те, в свою > очередь, из ["ключевых" и прочих] слов (operators, operations, expre- > ssions, values etc). Язык программирования что-ли? И на этом проектировать? Спасибо. Сами диаграммы, и внешний вид и размещение, связи > и пр. хранятся же тулами в каком-то виде. Но - каждый в своем, ибо uml- > языка нет. Ибо как им удобно так они их и хранят. А пользователю это представляется одинаково. Если определить язык как набор соглашений для передачи информации, то uml, idef, omt это все языки. Можно сказать по другому: графически язык - нотация. uml это нотация? Если - да, то это язык. > Что до методологии - я приводил пример. Если бы методология существовала > то, при следовании ей, одна и та же работа двух разных людей давала бы > (при реализации одного и того же) практически одинаковый результат. Давайте найдем более четкое определение методологии. А то единственной методологией будет инструкция для рабочего на конвейере. Автор: *"Max Belugin" * Дата: *Thu, 31 May 2001 14:46:36 +0000 (UTC)* Местное время: *Чт. 31 май 2001 15:46* Тема: *Re: моделирование бизнес-процессов* > Язык - это то, что состоит из предложений (statements), а те, в свою > очередь, из ["ключевых" и прочих] слов (operators, operations, expre- > ssions, values etc). Сами диаграммы, и внешний вид и размещение, связи > и пр. хранятся же тулами в каком-то виде. Но - каждый в своем, ибо uml- > языка нет. Несмотря на сокращение в аббревиатуре. Это текстовый язык состоит из слов, а UML из графических образов. А какие понятия стоят за UML описаны в UML Semantics guide. Существует еще, например, одно представление этих понятий - XMI. Можно, например взять и перенести модель из Rational Rose в ArgoUML. -- Отправлено через сервер Talk.Ru - http://www.talk.ru Автор: *"Vladimir Pavlikov" * Дата: *Thu, 31 May 2001 15:35:24 +0000 (UTC)* Местное время: *Чт. 31 май 2001 16:35* Тема: *Re: моделирование бизнес-процессов* Hello! "Max Belugin" wrote: > Это текстовый язык состоит из слов, а UML из графичесиз образов. А какие > понятия стоят за UML описаны в UML Semanticы guide. Существует еще, > например, одно представление этих понятий - XMI. Можно, например взять и > перенести модель из Rational Rose в ArgoUML. Образы это слова, до языка еще далеко. Язык можно проверить (автоматически) на формальную правильность, а OCL хоть и язык, но выполняет лишь малую часть этой работы, а мы все же о UML. Что до XMI - можно еще придумать "в количествах", это ничего не меняет. Да, я хотел бы иметь _стандартное_ текстовое представление : с ним можно работать в редакторе, проводить автоматическую обработку тулами (каковые нетрудно и написать, если понадобится), в том числе и "компилятором". А общение на "языке образов" понимают немногие, да и те по-разному. Я не о uml, я про художников :), но чем uml здесь принципиально лучше? -- Владимир Павликов. Отправлено через сервер Talk.Ru - http://www.talk.ru Автор: *"Serguei Tarassov" * Дата: *Thu, 31 May 2001 17:37:39 +0000 (UTC)* Местное время: *Чт. 31 май 2001 18:37* Тема: *Re: моделирование бизнес-процессов* Доброго дня! "Lev Yunak" wrote in message news: > Vladimir Pavlikov сообщил в новостях следующее: > > > Тогда что по вашему методология? > > > И что такое язык применительно для анализа и дизайна? Разве буква L в > > > аббревиатуре UML > > > не сокращение слова язык? > > Язык - это то, что состоит из предложений (statements), а те, в свою > > очередь, из ["ключевых" и прочих] слов (operators, operations, expre- > > ssions, values etc). > Язык программирования что-ли? И на этом проектировать? Спасибо. Есть и языки проектирования и языки описания систем. И далеко не все они имеют графическое представление. Любой формальный язык можно преобразовать в графические примитивы, обратное неверно. Картинки разных диаграмм UML в один язык никак не преобразуются. Это просто набор разных доморощенных методик, которые "три друга", не сумев выяснить кто из них "самый-самый друг", решили слить в одну канистру и продавать ее под вывеской "Объединенная живая вода" вместо "Коктейль для похудания". Понятна разница? Для IDEF преобразование в формальный язык тривиально. Диаграмма классов в UML - тоже. Вся модель в разных UML-позах - нет, нужно несколько языков. Зачем нужен формальный язык? Для того, чтобы в итоге получить, возможно и разными способами, но приводящий к одним и тем же результатам при своем выполнении машинный код. Машина не понимает неформальных языков. > Ибо как им удобно так они их и хранят. А пользователю это представляется > одинаково. Если определить язык как набор соглашений для > передачи информации, то uml, idef, omt это все языки. Можно сказать по > другому: > графически язык - нотация. uml это нотация? Если - да, то это язык. Нет, еще не язык. Точнее, еще не формальный язык. А неформальные нас интересуют не больше, чем текст в Word с картинками автора. > Давайте найдем более четкое определение методологии. А то единственной > методологией будет инструкция для рабочего на конвейере. МЕТОДОЛОГИЯ (от метод и ...логия), учение о структуре, логической организации, методах и средствах деятельности. И где в UML самое главное - метод? RUP - неправильный ответ, там нет ответа на вопрос "Как моделировать на UML". -- с уважением, Сергей Тарасов http://www.arbinada.com mailto:temp...@arbinada.com Автор: *"Max Belugin" * Дата: *Fri, 1 Jun 2001 06:44:46 +0000 (UTC)* Местное время: *Пт. 1 июн 2001 07:44* Тема: *Re: моделирование бизнес-процессов* > Образы это слова, до языка еще далеко. Язык можно проверить (автоматически) > на формальную правильность, а OCL хоть и язык, но выполняет лишь малую часть > этой работы, а мы все же о UML. Существует грамматика и семантика языка, описанная, как это не странно на самом этом языке и входящая в стандарт. >Что до XMI - можно еще придумать "в количес- > твах", это ничего не меняет. Поясните... > Да, я хотел бы иметь _стандартное_ текстовое представление : с ним можно > работать в редакторе, проводить автоматическую обработку тулами (каковые > нетрудно и написать, если понадобится), в том числе и "компилятором". Вы предпочитаете чтобы сначала ваша модель была представлена в виде текста, потом вы этот текст разобрали, опять восстановиви модель, потом скомпилировали из этого представление еще какое-то представление вашей модели? Тогда для вас - XMI Хотя почему бы не сразу скомпилировать объектную модель? > А общение на "языке образов" понимают немногие, да и те по-разному. >Я не о uml, я про художников :), но чем uml здесь принципиально лучше? Скорее это зависит от "художеств"... Попросите в ГАИ чтобы дорожные знаки сделали надписями, а то все их по-разному понимают. :) Интересно а текстовое представление вы понимаете через образы букв или непосредственно? :) 1) XMI - стандарт OMG 2) XMI - текстовое предстваление 3) для работы с UML не обязятельно текстовое представление - есть стандартная объектная модель описанная 4) Она реализована различными инструментами (Rational Rose, Novosoft UML library) И еще раз: стандарты вокруг UML можно условно разделить на две части: Метамодель UML - модель понятий, которые выражает UML - описана в Semantics Guide Различного рода представления UML: - Графическое представление описано UML Notation Guide - XML представление есть XMI - стандарт OMG Не все из этого идеально и хорошо проработано, но все-таки есть и худо бедно используется. Например в http://scrhostplugin.sf.net справка сделана путем компиляции XMI представления розовской модели. -- Отправлено через сервер Talk.Ru - http://www.talk.ru Автор: *"Lev Yunak" * Дата: *Fri, 1 Jun 2001 07:03:01 +0000 (UTC)* Местное время: *Пт. 1 июн 2001 08:03* Тема: *Re: моделирование бизнес-процессов* Serguei Tarassov сообщил в новостях следующее: > > > Язык - это то, что состоит из предложений (statements), а те, в свою > > > очередь, из ["ключевых" и прочих] слов (operators, operations, expre- > > > ssions, values etc). > > Язык программирования что-ли? И на этом проектировать? Спасибо. > Есть и языки проектирования и языки описания систем. И далеко не все они > имеют графическое представление. > Любой формальный язык можно преобразовать в > графические примитивы, обратное неверно. Почему? Есть же дорожные знаки и все их очень хорошо и вполне однозначно воспринимают. Не пойму что вас смущает в утверждении , что uml это язык. Ну назовите тогда другой язык анализа и проектирования. > Картинки разных диаграмм UML в один > язык никак не преобразуются. А что в языке есть ограничение на словарный запас? Какая разица сколько там диаграмм? Если они формально определены, да хоть 1000. Даже в idef их много: idef0, idef1x, idef3, idef5. Даже добавилось DFD. Или он тоже языком не является? > Это просто набор разных доморощенных методик, > которые "три друга", не сумев выяснить кто из них "самый-самый друг", решили > слить в одну канистру > Понятна разница? Для IDEF преобразование в формальный язык тривиально. Сомневаюсь. Приведите пример на IDEF, который тривиально преобразуется в формальный язык. И этот же пример на UML, который не преобразуется в этот же формальный язык. > Зачем нужен формальный язык? Для того, чтобы в итоге получить, возможно и > разными способами, но приводящий к одним и тем же результатам при своем > выполнении машинный код. ok. К одним и тем же результатам выполнения машинного кода может привести только язык программирования. Ни одна методика проектирования языком программирования не является! Методика проектирования - это язык для человека. Для того, чтобы два человека поняли друг друга. Есть следующие уровни коммуникации: 4. мысль (общение пока невозможно) 3. вербальный разговор (для человека не требуется особо напрягатся, но существует большая вероятность неправильного понимания, конфликты терминов...) 2. текст, графические представления, физические модели, вообщем все что воспринимается визуально (более формализованные правила, требует от человека жестче формулировать мысль) 1. спец языки для общения в определенных областях деятельности человка (чертежи по ЕСКД, дорожные знаки, правила написания пьес, сценариев в кино...) 0. языки, которые могут быть однозначно понятыми не только человеком, но и компьютером (машинный код, ассемблер, Си) Цель человека при общении - сделать путь от уровня 0 до уровня 4 как можно короче. UMLl и IDEF - уровень 1. Все методики проектирования находятся на уровне 1. Вы можете сделать mapping - схему преобразования модели(уровень1) в формальный язык(уровень 0) , но в ущерб гибкости модели. В Розе например есть соглашения по преобразованию классов в элементы структуры базы данных Oracle. Есть преобразование в C++, java, .... мы например из Use case делаем рабочие места и роли в Бд Oracle. Но для этого надо приложить дополнительные усилия, чтобы модель была адекватно преобразована. В частности - формализовать прецеденты низшего уровня для работы с объектами базы. > > графически язык - нотация. uml это нотация? Если - да, то это язык. > Нет, еще не язык. Точнее, еще не формальный язык. А неформальные нас > интересуют не больше, чем текст в Word с картинками автора. Никто его не позиционирует как язык программирования(уровень 0). Но и никто его не использует как просто картинки (уровень 3), которые человек-то не всегда понимает. > МЕТОДОЛОГИЯ (от метод и ...логия), учение о структуре, логической > организации, методах и средствах деятельности. > И где в UML самое главное - метод? ok. UML - не методогия. Метологией будеть OOAD в том числе RUP IDEF тоже не методология. Метологией является SADT > RUP - неправильный ответ, там нет ответа > на вопрос "Как моделировать на UML". Есть. Читаем RUP. И SADT заодно :) Автор: *"Ilya Zvyagin" * Дата: *Fri, 1 Jun 2001 08:17:26 +0000 (UTC)* Местное время: *Пт. 1 июн 2001 09:17* Тема: *Re: моделирование бизнес-процессов* Lev Yunak wrote in message >Язык программирования что-ли? И на этом проектировать? Спасибо. Ну действительно L в UML - скорее метафора. Естественно, что UML - не ЯЗЫК, а нотация (точнее набор нотаций). Автор: *"Serguei Tarassov" * Дата: *Fri, 1 Jun 2001 10:13:26 +0000 (UTC)* Местное время: *Пт. 1 июн 2001 11:13* Тема: *Re: моделирование бизнес-процессов* Доброго дня! "Lev Yunak" wrote in message > > Любой формальный язык можно преобразовать в > > графические примитивы, обратное неверно. > Почему? Есть же дорожные знаки и все их очень хорошо и вполне однозначно > воспринимают. И что ты поймешь, ежели на одном столбе будут висеть 3 знака: "ограничение скорости 90 км/ч", "впереди дети" и "через 100 метров тупик"? А еще есть рассказ Киплинга "Как было написано первое письмо". Тоже неплохая иллюстрация. > Не пойму что вас смущает в утверждении , что uml это язык. Ну назовите тогда > другой язык анализа и проектирования. Для анализа - IDEF0. Для проектирования - смотря что проектируем. Есть формальные языки описания hardware, например. Или чертеж детали. Или блок-схема алгоритма. Или описание на языке управления заданиями. Мало ли примеров. Все они формальны. > > Картинки разных диаграмм UML в один > > язык никак не преобразуются. > А что в языке есть ограничение на словарный запас? Какая разица сколько там > диаграмм? Для языков специфицирования - разумеется есть. Артефактов (по Оккаму), должно быть минимально необходимое количество. > Если они формально определены, да хоть 1000. Даже в idef их много: idef0, > idef1x, idef3, idef5. Даже добавилось DFD. Или он тоже языком не является? По отдельности являются. Но ума создателей, чтобы не объединять их в некий UML-IDEFL, все-таки хватило. Подумай, почему ;-) > > Понятна разница? Для IDEF преобразование в формальный язык тривиально. > Сомневаюсь. Приведите пример на IDEF, который тривиально преобразуется в > формальный язык. И этот же пример на UML, который не > преобразуется в этот же формальный язык. Любая функциональная декомпозиция на два-три уровня с обратными связями и доминированием. Попробуй то же описать, используя только одну нотацию из набора UML. > > Зачем нужен формальный язык? Для того, чтобы в итоге получить, возможно и > > разными способами, но приводящий к одним и тем же результатам при своем > > выполнении машинный код. > ok. К одним и тем же результатам выполнения машинного кода может привести > только язык программирования. Ни одна методика проектирования > языком программирования не является! Методика проектирования - это язык для > человека. Это неверено в корне. Любая модель имеет бОльшую семантику, чем программный код. Обратное неверно. Одна из целей, как ты выражаешься "языка проектирования" для программной системы - включить в себя семантику программного кода. Иначе получится, что программист будет обращаться к неформальным источникам, что является общей бедой в нашей отрасли. Интересно было бы посмотреть на токаря на авиазаводе, который идет к главному конструктору, так как ему не понятен смысл вытачиваемой заготовки. [рассуждения об уровнях безжалостно по-skip-аны] > Цель человека при общении - сделать путь от уровня 0 до уровня 4 как можно ^^^^^^^ ??? ты хотел сказать, при создании программной системы > короче. UMLl и IDEF - уровень 1. Все методики проектирования находятся на уровне 1. > Вы можете сделать mapping - схему преобразования модели(уровень1) в > формальный язык(уровень 0) , но > в ущерб гибкости модели. В Розе например есть соглашения по преобразованию ^^^^^^^^ ни в коем случае! Это не уменьшение гибкости, а формализация семантикики!!! > классов в элементы структуры базы данных Oracle. Есть преобразование в C++, > java, .... > мы например из Use case делаем рабочие места и роли в Бд Oracle. Но для > этого надо приложить дополнительные усилия, чтобы модель была адекватно > преобразована. > В частности - формализовать прецеденты низшего уровня для работы с объектами > базы. Вот вот. Значит изначально они не были формализованы, поэтому о методологии речи идти не может. То есть, методология все-таки появилась, но она уже называется по имени автора, то есть тебя, например ;-) Сам видишь, без нее никак. Пришлось бы программисту "на пальцах" объяснять, какие роли создать надо. > ok. UML - не методогия. Метологией будеть OOAD в том числе RUP > IDEF тоже не методология. Метологией является SADT Неверно. IDEF0 включает в себя методологию SADT и совсем немного добавляет свои формализмы и процедуры. > > RUP - неправильный ответ, там нет ответа > > на вопрос "Как моделировать на UML". > Есть. Читаем RUP. И SADT заодно :) Ссылку на главу и раздел из RUP в студию!!! -- с уважением, Сергей Тарасов http://www.arbinada.com mailto:temp...@arbinada.com Автор: *"Max Belugin" * Дата: *Fri, 1 Jun 2001 13:28:05 +0000 (UTC)* Местное время: *Пт. 1 июн 2001 14:28* Тема: *Re: моделирование бизнес-процессов* > > Есть. Читаем RUP. И SADT заодно :) > Ссылку на главу и раздел из RUP в студию!!! Какая часть моделирования на UML тебя интересует? Вот например есть Activity: Find Actors and Use Cases Find Actors Finding actors is one of the first steps in defining system use. Each type of external phenomenon with which the system must interact is represented by an actor. To find the actors, ask the following questions: a.. Which user groups require help from the system to perform their tasks? b.. Which user groups are needed to execute the system's most obvious main functions? c.. Which user groups are required to perform secondary functions, such as system maintenance and administration? d.. Will the system interact with any external hardware or software system? Any individual, group or phenomenon that fits one or more of these categories is a candidate for an actor. To determine whether you have the right (human) actors, you can try to name two or three people who can perform as actors, and then see if your set of actors is sufficient for their needs. For more on what constitutes an actor, see Guidelines: Actor. Чем плохо? Автор: *"Serguei Tarassov" * Дата: *Fri, 1 Jun 2001 17:29:44 +0000 (UTC)* Местное время: *Пт. 1 июн 2001 18:29* Тема: *Re: моделирование бизнес-процессов* Доброго дня! "Max Belugin" wrote in message > > > Есть. Читаем RUP. И SADT заодно :) > > Ссылку на главу и раздел из RUP в студию!!! > Какая часть моделирования на UML тебя интересует? 5 баллов! Какая часть автомобиля тебе нужна чтобы ездить? Я не против UML, но ты свим вопросом лишний раз подтвердил, что это не единая методология, а набор методик разных авторов, не имеющих "общего стержня". > Чем плохо? Избыточностью, противоричивостью и неопределенностью. -- с уважением, Сергей Тарасов http://www.arbinada.com mailto:temp...@arbinada.com Автор: *Sergei Novikov * Дата: *Sun, 03 Jun 2001 21:27:38 +0400* Местное время: *Вс. 3 июн 2001 18:27* Тема: *моделирование бизнес-процессов* ST> Я не против UML, но ты свим вопросом лишний раз подтвердил, что это не ST> единая методология, а набор методик разных авторов, не имеющих "общего ST> стержня". Автор как раз один - Rational Software (Бутч, Якобсон и ещё один, фамилию забыл) Автор: *Sergei Novikov * Дата: *Sun, 03 Jun 2001 21:25:04 +0400* Местное время: *Вс. 3 июн 2001 18:25* Тема: *моделирование бизнес-процессов* >> > > А в uml я не вижу ни методологии, ни языка... >> > ???? Поясните плиз. >> Что именно пояснить? Стандартизацию визуальных элементов вижу, язык >> и методологию - нет. RUP - это уже не вполне uml, да и он не вполне >> методология. Это, скорее, пояснять (мне и другим) стоит тому, кто >> видит. LY> Тогда что по вашему методология? LY> И что такое язык применительно для анализа и дизайна? Разве буква L в LY> аббревиатуре UML LY> не сокращение слова язык? РУП - методология по определению. Методология создания ИС с использованием продуктов Rational. Что интересно, в Computer Associates's Paradigm Plus - своя методология (Catalisys), поддержка UML, SADT и проч. Кстати, есть мнение, что Paradigm Plus будет получше Розы, хоть и менее раскручен. Кто что думает? *Sergei*. Fight fire with fire. I said fight fire with fire. Автор: *"Lev Yunak" * Дата: *Mon, 4 Jun 2001 08:48:06 +0000 (UTC)* Местное время: *Пн. 4 июн 2001 09:48* Тема: *Re: моделирование бизнес-процессов* Serguei Tarassov сообщил в новостях следующее: > > > Любой формальный язык можно преобразовать в > > > графические примитивы, обратное неверно. > > Почему? Есть же дорожные знаки и все их очень хорошо и вполне однозначно > > воспринимают. > И что ты поймешь, ежели на одном столбе будут висеть 3 знака: "ограничение > скорости 90 км/ч", "впереди дети" и "через 100 метров тупик"? Ну и что здесь неоднозначного? > > Не пойму что вас смущает в утверждении , что uml это язык. Ну назовите тогда > > другой язык анализа и проектирования. > Для анализа - IDEF0. Для проектирования - смотря что проектируем. Есть > формальные языки описания hardware, например. Или чертеж детали. Или > блок-схема алгоритма. Или описание на языке управления заданиями. Мало ли > примеров. Все они формальны. IDEF0 формальный язык? Можно из него получить машинный код? > > > Картинки разных диаграмм UML в один > > > язык никак не преобразуются. > > А что в языке есть ограничение на словарный запас? Какая разица сколько там > > диаграмм? > Для языков специфицирования - разумеется есть. Артефактов (по Оккаму), > должно быть минимально необходимое количество. Так и есть - необходимо и достаточно. Ну не ужели вы думаете, что в rational дураки работают? > > Если они формально определены, да хоть 1000. Даже в idef их много: idef0, > > idef1x, idef3, idef5. Даже добавилось DFD. Или он тоже языком не является? > По отдельности являются. Но ума создателей, чтобы не объединять их в некий > UML-IDEFL, все-таки хватило. Так они же объединены в IDEF. IDEF (0,1,3,5) => IDEF Use case, Class diagram, Component, + .. => UML > > > Понятна разница? Для IDEF преобразование в формальный язык тривиально. > > Сомневаюсь. Приведите пример на IDEF, который тривиально преобразуется в > > формальный язык. И этот же пример на UML, который не > > преобразуется в этот же формальный язык. > Любая функциональная декомпозиция на два-три уровня с обратными связями и > доминированием. Это не пример. Дайте конкретный пример - тот же пресловутый заказ авиабилетов например. > Попробуй то же описать, используя только одну нотацию из набора UML. Я вас не ограничиваю в IDEF, а вы меня не ограничивайте в UML Мое утверждение такое: и c IDEF и c UML можно смоделировать систему. Это будет выглядеть по-разному, это будет однозначно для человека и не однозначно для компьютера. Однозначно для компьютера это будет только тогда, когда мы опишем дополнительные соглашения, которые будут определять как генерировать машинный код. Изначально методики проектирования этого не содержат. > [рассуждения об уровнях безжалостно по-skip-аны] > > Цель человека при общении - сделать путь от уровня 0 до уровня 4 как можно > ^^^^^^^ ??? ты хотел сказать, при создании программной системы Общение в общем смысле слова. человек-человек, человек-компьютер. > > UMLl и IDEF - уровень 1. Все методики проектирования находятся на уровне 1. > > Вы можете сделать mapping - схему преобразования модели(уровень1) в > > формальный язык(уровень 0) , но > > в ущерб гибкости модели. В Розе например есть соглашения по преобразованию > ^^^^^^^^ ни в коем случае! Это не уменьшение гибкости, а > формализация семантикики!!! пардон. Не в ущерб гибкости модели, а в ущерб гибкости языка на котором это описывается. > > Есть преобразование в C++, java, .... > Вот вот. Значит изначально они не были формализованы, поэтому о методологии > речи идти не может. Оракл, C++... это уже реализация. Существет слишком много реализаций, чтобы их заносить в методику проектирования. В IDEF этого тоже нет. И это правильно. > > ok. UML - не методогия. Метологией будеть OOAD в том числе RUP > > IDEF тоже не методология. Метологией является SADT > Неверно. IDEF0 включает в себя методологию SADT и совсем немного добавляет > свои формализмы и процедуры. Если быть дословным, то IDEF0 основан на SADT. Но методологией не является, так как не содержит ответа на вас же вопрос "Как моделировать" Там есть ответ на вопрос "как нарисовать моделируемое". > > > RUP - неправильный ответ, там нет ответа > > > на вопрос "Как моделировать на UML". > > Есть. Читаем RUP. И SADT заодно :) > Ссылку на главу и раздел из RUP в студию!!! У Новикова "Введение в RUP" Главы 8,9,10 "Деловое моделирование" (www.interface.ru ) В самом RUP могу найти если нужно, но там на английском. Автор: *"Max Belugin" * Дата: *Mon, 4 Jun 2001 12:49:34 +0000 (UTC)* Местное время: *Пн. 4 июн 2001 13:49* Тема: *Re: моделирование бизнес-процессов* > > > > Есть. Читаем RUP. И SADT заодно :) > > > Ссылку на главу и раздел из RUP в студию!!! > > Какая часть моделирования на UML тебя интересует? > 5 баллов! > Какая часть автомобиля тебе нужна чтобы ездить? Я выступаю исключительно в роли пассажира. Если кабина перемещается в нужном мне направлении за нужную цену и нужное время - мне плевать на остальные части автомобиля. > Я не против UML, но ты свим вопросом лишний раз подтвердил, что это не > единая методология, а набор методик разных авторов, не имеющих "общего > стержня". Неа, я подтвердил, что UML состоит из частей, так же как и автомобиль. Если Вас интересует UML в целом - берите RUP в целом - тогда ссылка будет на корневой раздел. Если вас интересует какая-то конкретная часть UML - в РУП есть процессы, результатом которых являются те или иные диаграммы UML в том или ином состоянии. -- Отправлено через сервер Talk.Ru - http://www.talk.ru Автор: *"Max Belugin" * Дата: *Mon, 4 Jun 2001 12:49:35 +0000 (UTC)* Местное время: *Пн. 4 июн 2001 13:49* Тема: *Re: моделирование бизнес-процессов* Rumbaugh Приветствую, "Sergei Novikov" ! Вы сообщили: > Автор как раз один - Rational Software (Бутч, Якобсон и ещё один, фамилию > забыл) Отправлено через сервер Talk.Ru - http://www.talk.ru Автор: *"Vladimir Pavlikov" * Дата: *Mon, 4 Jun 2001 12:51:35 +0000 (UTC)* Местное время: *Пн. 4 июн 2001 13:51* Тема: *Re: моделирование бизнес-процессов* Hello! "Sergei Novikov" wrote: > Кстати, есть мнение, что > Paradigm Plus будет получше Розы, хоть и менее раскручен. Кто что думает? Мнение основано на личном опыте/впечатлениях? Тогда интересно его сравнение с together. Ибо есть мнение, что по сравнению с последней роза - жалкая поделка :) Не мое, но и мне тугеза нравится больше. -- Владимир Павликов. Отправлено через сервер Talk.Ru - http://www.talk.ru Автор: *"Vladimir Pavlikov" * Дата: *Mon, 4 Jun 2001 12:51:35 +0000 (UTC)* Местное время: *Пн. 4 июн 2001 13:51* Тема: *Re: моделирование бизнес-процессов* Hello! "Max Belugin" wrote: > Существует грамматика и семантика языка, описанная, как это не странно на > самом этом языке и входящая в стандарт. Видимо, меня не удовлетворили эти описания, раз я не считаю описанное языком? > >Что до XMI - можно еще придумать "в количествах", это ничего не меняет. > Поясните... Что именно? XMI - это не UML... > Вы предпочитаете чтобы сначала ваша модель была представлена в виде текста, > потом вы этот текст разобрали, опять восстановиви модель, потом > скомпилировали из этого представление еще какое-то представление вашей > модели? Тогда для вас - XMI Нет, вот "сначала-потом" меня прежде всего и не устраивает. Было конкретно спрошено мое мнение. Я коротко ответил. У меня не было цели втягиваться в обсуждение, тем более - переубеждать кого-то. И все же - вынужден ответить подробнее. Итак : Моделирование - это (по-моему) процесс _разработки_ модели, некое "интел- лектуальное" действие. UML же, несмотря на потуги, скрытые в расшифровке этой аббревиатуры, годится (ограниченно) не для самого процесса, а лишь для описания/иллюстрирования результата. То, что не конечного, а может использоваться и "на проходе", принципиально ничего не меняет. Собственно, это вовсе не претензия - я и не рассчитываю получить инструмент анализа/ проектирования/моделирования - речь о констатации факта. Но меня не очень устраивает и его иллюстрирование. Разработчики совершили _главную_ ошибку - не сформулировали систему требований и ограничений. Даже в языках програм- мирования (имеющих несравнимо более узкую "рабочую область") это может привести (и приводит) к непониманию и неоптимальному коду, здесь же ситу- ация выглядит намного хуже. Ну и второе, с чего и начался разговор - язык. Я _не_ против визуального представления, я за. Но почему оно единственно? Оно же однозначно отобразимо на текстовое (языковое, без кавычек) представление. Возьми язык С и попробуй подсчитать, какое количество инструментов (разных типов) его "понимает", позволяя нам выполнять самые разные задачи. А с картинками работать не умеет ни один тул... Кстати, большинство UML-инструментов могут работать с разными языками программирования, но - лишь на уровне импорт-экспорт :( Хотя та же Together с явой работает именно в режиме two-way, но это же не значит, что ява является текстовым представлением uml :) Нужна не привязка в яве-плюсам и т.д., нужно именно текстовое представление _всего_ uml (ключая юзкейсы и пр., явами не представимое), и именно оно и должно быть моделью. Отображаемой (в том числе) и в виде графических диаг- рамм. Только в этом случае можно будет работать с одной и той же моделью _разными_ инструментами (какой кому нравится), а вот восприниматься модель будет всеми (имеющими представление о языке) _одинаково_. Плюс бонус в виде возможности автоматически обрабатывать модели разними тулами, хотя бы и самописными. А не только розой (тугезой, визио, арго и т.д. - но в каждом случае только одним). Резюме простое - UML это не M (лишь рисовалка), не L (до языка ему далеко). И, и по этим, и по некоторым другим причинам - не U. Предвосхищая вопрос - да, ничего меня устраивающего на рынке нет. Да, пользую в том числе и uml в real-life - а что делать? Но не считаю это основанием выдавать жедаемое за действительное. > Попросите в ГАИ чтобы дорожные знаки сделали надписями, а то все их > по-разному понимают. :) Это неверно - знающие ПДД понимают их одинаково. И потому, что там знаки - это самодостаточные вещи (а не части диаграмм и групп диаграмм, в их взаимосвязи), и потому, что требования и ограничения жестко прописаны. > Интересно а текстовое представление вы понимаете через образы букв или > непосредственно? :) Разумеется, непосредственно. Хотя бы потому, что написанное кривым почерком и перепечатанное затем на машинке для меня означает ровно одно и то же. Вопросы вроде бы шуточные, но предмет освещают неплохо... > 1) XMI - стандарт OMG > 2) XMI - текстовое предстваление Не вижу uml. > 3) для работы с UML не обязятельно текстовое представление _Кому_ необязятельно ? Мне - так очень важно. Настолько, что пока мне трудно вообще говорить о _работе_ в разговоре о uml. > - есть стандартная объектная модель описанная > 4) Она реализована различными инструментами (Rational Rose, Novosoft UML library) И каждым по своему, между собой несовместимы ... > Не все из этого идеально и хорошо проработано, но все-таки есть и худо бедно > используется. Кому нужно что-то лишь потому, что оно есть? Что до использования - я и не возражаю против существования фирм/проектов, в которых время (и деньги), потраченные на "рисование" - "худо-бедно" были покрыты экономией времени и денег в тех же размерах (т.е. в конечном итоге не дали ничего). В конце концов так или иначе проекты (и модели) документировались всегда, только не стоит называть это моделированием и языком... -- Владимир Павликов. Отправлено через сервер Talk.Ru - http://www.talk.ru Автор: *"Max Belugin" * Дата: *Mon, 4 Jun 2001 14:08:58 +0000 (UTC)* Местное время: *Пн. 4 июн 2001 15:08* Тема: *Re: моделирование бизнес-процессов* > > Существует грамматика и семантика языка, описанная, как это не странно на > > самом этом языке и входящая в стандарт. > Видимо, меня не удовлетворили эти описания, раз я не считаю описанное языком? Я и пытаюсь узнать, чем конкретно... > > >Что до XMI - можно еще придумать "в количествах", это ничего не меняет. > > Поясните... > Что именно? XMI - это не UML... XMI является одним из представлений UML, не включенным в UML, но стандартом той же организации OMG > > Вы предпочитаете чтобы сначала ваша модель была представлена в виде текста, > > потом вы этот текст разобрали, опять восстановиви модель, потом > > скомпилировали из этого представление еще какое-то представление вашей > > модели? Тогда для вас - XMI > Нет, вот "сначала-потом" меня прежде всего и не устраивает. Я имел ввиду, что чтобы осмысленно работать с моделью надо обладать метамоделью, а не текстом, который ее представляет. Иначе вам придется конструировать на его основе свою, нестандартную. Стандартная метамодель есть и она описана. > Моделирование - это (по-моему) процесс _разработки_ модели, некое "интел- > лектуальное" действие. UML же, несмотря на потуги, скрытые в расшифровке > этой аббревиатуры, годится (ограниченно) не для самого процесса, а лишь > для описания/иллюстрирования результата. Да. Процесс - RUP То, что не конечного, а может > использоваться и "на проходе", принципиально ничего не меняет. Собственно, > это вовсе не претензия - я и не рассчитываю получить инструмент анализа/ > проектирования/моделирования - речь о констатации факта. Но меня не очень > устраивает и его иллюстрирование. Разработчики совершили _главную_ ошибку - > не сформулировали систему требований и ограничений. Даже в языках програм- > мирования (имеющих несравнимо более узкую "рабочую область") это может > привести (и приводит) к непониманию и неоптимальному коду, здесь же ситу- > ация выглядит намного хуже. Может быть, правильней сказать, что они описаны недостаточно детально? Какие ограничения вы бы добали в UML, хоть одно для примера? > Нужна не привязка в яве-плюсам и т.д., нужно именно текстовое представление > _всего_ uml (ключая юзкейсы и пр., явами не представимое), и именно оно и > должно быть моделью. Отображаемой (в том числе) и в виде графических диаг- > рамм. Только в этом случае можно будет работать с одной и той же моделью > _разными_ инструментами (какой кому нравится), а вот восприниматься модель > будет всеми (имеющими представление о языке) _одинаково_. Плюс бонус в виде > возможности автоматически обрабатывать модели разними тулами, хотя бы и > самописными. А не только розой (тугезой, визио, арго и т.д. - но в каждом > случае только одним). Если вы хотите работать с моделью, у инструментов есть API и оно должно представлять стандартную объектную модель, которая сформулирована в стандарте. Если вы хотите работать с текстом - есть текстовое представление. > > Интересно а текстовое представление вы понимаете через образы букв или > > непосредственно? :) > Разумеется, непосредственно. Хотя бы потому, что написанное кривым почерком > и перепечатанное затем на машинке для меня означает ровно одно и то же. Странно, и каким органом вы это делаете - если глазами, то они работают с образами. > > 1) XMI - стандарт OMG > > 2) XMI - текстовое предстваление > Не вижу uml. What are the objectives of XMI? To allow the exchange of objects and software assets throughout your application development environments from the OMG's Object Analysis and Design Facility. These objects are more commonly described as UML (Unified Modeling Language) and MOF (Meta Objects Facility). XMI is the new industry standard way of doing this, which avoids creating a variety of proprietary formats, each specific to a vendor tool. Also, XMI is intended to be a "stream" format. That is, it can either be stored in a traditional file system or streamed across the Internet from a database or repository. http://www-4.ibm.com/software/ad/standards/xmi.html > > 3) для работы с UML не обязятельно текстовое представление > _Кому_ необязятельно ? Мне - так очень важно. Настолько, что пока > мне трудно вообще говорить о _работе_ в разговоре о uml. > > - есть стандартная объектная модель описанная > > 4) Она реализована различными инструментами (Rational Rose, Novosoft UML library) > И каждым по своему, между собой несовместимы ... Вы сколько инструментов используете? Приведите пример задачи которая решается очень трудно? > Кому нужно что-то лишь потому, что оно есть? Что до использования - я и не > возражаю против существования фирм/проектов, в которых время (и деньги), > потраченные на "рисование" - "худо-бедно" были покрыты экономией времени > и денег в тех же размерах (т.е. в конечном итоге не дали ничего). В конце > концов так или иначе проекты (и модели) документировались всегда, только > не стоит называть это моделированием и языком... Какие задачи не решаются. Приведите конкретный пример (я тогда-то хотел сделать то-то а не получилось, поому, что UML не текстовый формат) -- Отправлено через сервер Talk.Ru - http://www.talk.ru Автор: *Sergei Novikov * Дата: *Mon, 04 Jun 2001 23:11:32 +0400* Местное время: *Пн. 4 июн 2001 20:11* Тема: *моделирование бизнес-процессов* >> Кстати, есть мнение, что >> Paradigm Plus будет получше Розы, хоть и менее раскручен. Кто что думает? VP> Мнение основано на личном опыте/впечатлениях? Тогда интересно его VP> сравнение с together. Ибо есть мнение, что по сравнению с последней роза - VP> жалкая поделка :) Hе мое, но и мне тугеза нравится больше. -- А это что за зверь? Первый раз слышу. Чей, скока стОит, где найти инфу на русском? *Sergei*. Fight fire with fire. I said fight fire with fire. Автор: *Sergei Novikov * Дата: *Mon, 04 Jun 2001 23:10:44 +0400* Местное время: *Пн. 4 июн 2001 20:10* Тема: *моделирование бизнес-процессов* >> Автор как раз один - Rational Software (Бутч, Якобсон и ещё один, >> фамилию MB> Rumbaugh Кстати, ходили слухи, будто Бутч из Рэшнл свалил :) *Sergei*. Fight fire with fire. I said fight fire with fire. Автор: *"Vladimir Pavlikov" * Дата: *Tue, 5 Jun 2001 09:36:35 +0000 (UTC)* Местное время: *Вт. 5 июн 2001 10:36* Тема: *Re: моделирование бизнес-процессов* Hello! "Sergei Novikov" wrote: > VP> Мнение основано на личном опыте/впечатлениях? Тогда интересно его > VP> сравнение с together. Ибо есть мнение, что по сравнению с последней роза - > VP> жалкая поделка :) Hе мое, но и мне тугеза нравится больше. -- > А это что за зверь? Первый раз слышу. Чей, скока стОит, где найти инфу на > русском? На русском не знаю, стоимость нужно конкретно запрашивать, остальное - на www.togethersoft.com . Только учти - ему 256 Мег мало :) -- Владимир Павликов. Отправлено через сервер Talk.Ru - http://www.talk.ru Автор: *"Serguei Tarassov" * Дата: *Tue, 5 Jun 2001 10:29:41 +0000 (UTC)* Местное время: *Вт. 5 июн 2001 11:29* Тема: *Re: моделирование бизнес-процессов* Доброго дня! "Sergei Novikov" wrote in message news: > ST> Я не против UML, но ты свим вопросом лишний раз подтвердил, что это не > ST> единая методология, а набор методик разных авторов, не имеющих "общего > ST> стержня". > Автор как раз один - Rational Software (Бутч, Якобсон и ещё один, фамилию забыл) И было так. И собрались как-то после многолетней войны Буч, Рамбо и Якобсон, выпили по 200 и решили делать деньги вместе. И слили свои доморощенные методики в одну. И дали ей имя UML... -- с уважением, Сергей Тарасов http://www.arbinada.com mailto:temp...@arbinada.com Автор: *"Max Belugin" * Дата: *Tue, 5 Jun 2001 11:08:20 +0000 (UTC)* Местное время: *Вт. 5 июн 2001 12:08* Тема: *Re: моделирование бизнес-процессов* Приветствую, "Serguei Tarassov" ! Вы сообщили: > > Автор как раз один - Rational Software (Бутч, Якобсон и ещё один, фамилию > > забыл) > И было так. И собрались как-то после многолетней войны Буч, Рамбо и Якобсон, > выпили по 200 и решили делать деньги вместе. И слили свои доморощенные > методики в одну. И дали ей имя UML... Во-первых, UML - это не методика Во-вторых, приведи альтернативы, которые тебе больше нравятся. Очень интересуют методики (типа Catalysis) -- Max Belugin http://belugin.newmail.ru ICQ:9406811 Автор: *"Vladimir Pavlikov" * Дата: *Tue, 5 Jun 2001 11:59:13 +0000 (UTC)* Местное время: *Вт. 5 июн 2001 12:59* Тема: *Re: моделирование бизнес-процессов* Hello! "Max Belugin" wrote: > XMI является одним из представлений UML, не включенным в UML, но стандартом > той же организации OMG Я и говорю - не включенным в UML. Таких можно наделать сколько угодно, и уже делаются. А _одного_ - нет :( > > Нет, вот "сначала-потом" меня прежде всего и не устраивает. > Я имел ввиду, что чтобы осмысленно работать с моделью надо обладать > метамоделью, а не текстом, который ее представляет. Иначе вам придется > конструировать на его основе свою, нестандартную. Стандартная метамодель > есть и она описана. Метамодель без представления - это что? Картинки - это тоже представление, именно оно (как единственное) и не устраивает. Я хочу иметь возможность работать с метамоделью, разными способами - для этого требуется подходя- щее представление, и единственное (стандартизованное, uml-ское) меня совершенно не устраивает. Почему - об этом и пишу. > > Моделирование - это (по-моему) процесс _разработки_ модели, некое "интел- > > лектуальное" действие. UML же, несмотря на потуги, скрытые в расшифровке > > этой аббревиатуры, годится (ограниченно) не для самого процесса, а лишь > > для описания/иллюстрирования результата. > Да. Процесс - RUP Частичный, и не uml-ский - Розовский. Ты уверен, что он применим с другими? > > Разработчики совершили _главную_ ошибку - > > не сформулировали систему требований и ограничений. Даже в языках програм- > > мирования (имеющих несравнимо более узкую "рабочую область") это может > > привести (и приводит) к непониманию и неоптимальному коду, здесь же ситу- > > ация выглядит намного хуже. > Может быть, правильней сказать, что они описаны недостаточно детально? > Какие ограничения вы бы добали в UML, хоть одно для примера? Недостаточно детально? А есть ли вообще? Я могу составить огромный пере- чень, но нужен ли?, по моему, многое довольно очевидно. Может, попозже. > Если вы хотите работать с моделью, у инструментов есть API и оно должно > представлять стандартную объектную модель, которая сформулирована в > стандарте. Если вы хотите работать с текстом - есть текстовое представление. Нет текстового представления! Единого, обязательного для всех, полноценно описывающего модель. Не только текстового - никакого. А АПИ конкретных инструментов при разговоре о "универсальном языке" не имеет оснований для упоминания - к теме не относится. > > > Интересно а текстовое представление вы понимаете через образы букв или > > > непосредственно? :) > > Разумеется, непосредственно. Хотя бы потому, что написанное кривым почерком > > и перепечатанное затем на машинке для меня означает ровно одно и то же. > Странно, и каким органом вы это делаете - если глазами, то они работают с > образами. Понимание - функция мозга... > > > 4) Она реализована различными инструментами (Rational Rose, Novosoft UML library) > > И каждым по своему, между собой несовместимы ... > Вы сколько инструментов используете? Приведите пример задачи которая > решается очень трудно? При чем тут я? Текст, написанный на ANSI C, я могу успешно скомпилировать на нескольких десятках инструментов, как минимум. И реально использовал уже больше десятка. Потому, что речь идет о _языке_, а не о ... ладно :) На uml решается только одна задача - изобразительная. И то - есть проблемы с воспринимаемостью. Остальные не просто трудно - они нерешимы. > > Кому нужно что-то лишь потому, что оно есть? Что до использования - я и не > > возражаю против существования фирм/проектов, в которых время (и деньги), > > потраченные на "рисование" - "худо-бедно" были покрыты экономией времени > > и денег в тех же размерах (т.е. в конечном итоге не дали ничего). В конце > > концов так или иначе проекты (и модели) документировались всегда, только > > не стоит называть это моделированием и языком... > Какие задачи не решаются. Приведите конкретный пример (я тогда-то хотел > сделать то-то а не получилось, поому, что UML не текстовый формат) Мах, я ответил на вопрос. И коротко, и расширенно. И хотел бы знать причины, по которым я должен описывать задачи, над которыми работаю, причины, по кото- рым для их решения uml не слишком хорош, и рассказывать, почему. Объем большой, и причины должны быть вескими. Ни доказывание того, что я не верблюд, ни переубеждение других таковыми не являются. А другие есть? -- Владимир Павликов. Отправлено через сервер Talk.Ru - http://www.talk.ru Автор: *"Max Belugin" * Дата: *Tue, 5 Jun 2001 12:29:47 +0000 (UTC)* Местное время: *Вт. 5 июн 2001 13:29* Тема: *Re: моделирование бизнес-процессов* > Метамодель без представления - это что? Картинки - это тоже представление, > именно оно (как единственное) и не устраивает. Я хочу иметь возможность > работать с метамоделью, разными способами - для этого требуется подходя- > щее представление, и единственное (стандартизованное, uml-ское) меня > совершенно не устраивает. Почему - об этом и пишу. Де факто XMI по-моему единственное текстовое представление от OMG. Или я ошибаюсь? Okay. Я имел ввиду представление в объектной среде. С моей точки зрения правильно работать через API (через DOM, а не через XML, через ADO, а не через CSV). Оно не стандартизировано, но объектная модель для него есть. > > > Моделирование - это (по-моему) процесс _разработки_ модели, некое "интел- > > > лектуальное" действие. UML же, несмотря на потуги, скрытые в расшифровке > > > этой аббревиатуры, годится (ограниченно) не для самого процесса, а лишь > > > для описания/иллюстрирования результата. > > Да. Процесс - RUP > Частичный, и не uml-ский - Розовский. Ты уверен, что он применим с другими? Не уверен. > > > Разработчики совершили _главную_ ошибку - > > > не сформулировали систему требований и ограничений. Даже в языках програм- > > > мирования (имеющих несравнимо более узкую "рабочую область") это может > > > привести (и приводит) к непониманию и неоптимальному коду, здесь же ситу- > > > ация выглядит намного хуже. > > Может быть, правильней сказать, что они описаны недостаточно детально? > > Какие ограничения вы бы добали в UML, хоть одно для примера? > Недостаточно детально? А есть ли вообще? Я могу составить огромный пере- > чень, но нужен ли?, по моему, многое довольно очевидно. Может, попозже. Я просил зоть одно для примера, иллюстрации. > > > > 4) Она реализована различными инструментами (Rational Rose, Novosoft UML library) > > > И каждым по своему, между собой несовместимы ... > > Вы сколько инструментов используете? Приведите пример задачи которая > > решается очень трудно? > При чем тут я? Текст, написанный на ANSI C, я могу успешно скомпилировать > на нескольких десятках инструментов, как минимум. И реально использовал > уже больше десятка. Потому, что речь идет о _языке_, а не о ... ладно :) С объектами, написанными на любом языке под .NET можно работать на любом другом, так как там стандартизирован runtimе - то есть набор понятий. Есть понятия, есть нотация, для обмена между разными интрументами есть XMI. У текущей реализации этого всего есть недостатки, но это все есть. > На uml решается только одна задача - изобразительная. И то - есть проблемы > с воспринимаемостью. >Остальные не просто трудно - они нерешимы. На практике решают. Стандарты есть. Неидеальны. > > Какие задачи не решаются. Приведите конкретный пример (я тогда-то хотел > > сделать то-то а не получилось, поому, что UML не текстовый формат) > Мах, я ответил на вопрос. И коротко, и расширенно. И хотел бы знать причины, > по которым я должен описывать задачи, над которыми работаю, причины, по кото- > рым для их решения uml не слишком хорош, и рассказывать, почему. Ничего вы никому не должны. > Объем большой, и причины должны быть вескими. Я не требую перечисления всего. Просто маленький пример. >Ни доказывание того, что я не верблюд, > ни переубеждение других таковыми не являются. А другие есть? А зачем вы вообще все это пишете? Наверное, у вас есть какие-то причины. А мне хотелось бы перейти от спора к рассмотрению конкретных недостатков UML. Возможно, при этом рассмотрении можно перейти к способам минимизации их последствий или их обходу. -- Отправлено через сервер Talk.Ru - http://www.talk.ru Автор: *"Lev Yunak" * Дата: *Tue, 5 Jun 2001 12:29:46 +0000 (UTC)* Местное время: *Вт. 5 июн 2001 13:29* Тема: *Re: моделирование бизнес-процессов* Vladimir Pavlikov сообщил в новостях следующее: > > XMI является одним из представлений UML, не включенным в UML, но стандартом > > той же организации OMG > Я и говорю - не включенным в UML. Таких можно наделать сколько угодно, > и уже делаются. А _одного_ - нет :( Тебе человек дело предлагает. XMI уже есть и другого придумывать не надо. Используй. Что зря спорить. Или ты начнешь спорить насчет буквы I ? :) Вон Серяков в mo.job.talk вообще крамолу сказал: "разработка - передача понимания" :) Автор: *"Serguei Tarassov" * Дата: *Tue, 5 Jun 2001 15:20:41 +0000 (UTC)* Местное время: *Вт. 5 июн 2001 16:20* Тема: *Re: моделирование бизнес-процессов* Доброго дня! "Lev Yunak" wrote in message news: > > И что ты поймешь, ежели на одном столбе будут висеть 3 знака: "ограничение > > скорости 90 км/ч", "впереди дети" и "через 100 метров тупик"? > Ну и что здесь неоднозначного? Удачи на дорогах... > > > Не пойму что вас смущает в утверждении , что uml это язык. Ну назовите тогда > > > другой язык анализа и проектирования. > > Для анализа - IDEF0. Для проектирования - смотря что проектируем. Есть > > формальные языки описания hardware, например. Или чертеж детали. Или > > блок-схема алгоритма. Или описание на языке управления заданиями. Мало ли > > примеров. Все они формальны. > IDEF0 формальный язык? Можно из него получить машинный код? Теоретически можно, но не нужно. Цели у него другие. Формальность языка означает однозначность понятий. > > Для языков специфицирования - разумеется есть. Артефактов (по Оккаму), > > должно быть минимально необходимое количество. > Так и есть - необходимо и достаточно. Ну не ужели вы думаете, > что в rational дураки работают? Веский аргумент... > > По отдельности являются. Но ума создателей, чтобы не объединять их в некий > > UML-IDEFL, все-таки хватило. > Так они же объединены в IDEF. > IDEF (0,1,3,5) => IDEF > Use case, Class diagram, Component, + .. => UML Замечательно. Смотри на свои слова ниже, про то, что тебе не хватает одной нотации. Еще раз предлагаю описать несложную модель в IDEF0 и на прецедентах. И оценить информативность модели. > Это не пример. Дайте конкретный пример - тот же пресловутый заказ > авиабилетов например. Например, отгрузка товара со склада. > > Попробуй то же описать, используя только одну нотацию из набора UML. > Я вас не ограничиваю в IDEF, а вы меня не ограничивайте в UML См.выше... > Мое утверждение такое: и c IDEF и c UML можно смоделировать систему. > Это будет выглядеть по-разному, это будет однозначно для человека и > не однозначно для компьютера. Однозначно для компьютера это будет только > тогда, когда мы опишем дополнительные соглашения, которые будут определять > как генерировать машинный код. Изначально методики проектирования > этого не содержат. Как определить масштаб модели в UML? > > > Есть преобразование в C++, java, .... > > Вот вот. Значит изначально они не были формализованы, поэтому о методологии > > речи идти не может. > Оракл, C++... это уже реализация. Существет слишком много реализаций, чтобы > их заносить в методику проектирования. В IDEF этого тоже нет. И это правильно. А в диаграмме классов есть... > > > > RUP - неправильный ответ, там нет ответа > > > > на вопрос "Как моделировать на UML". > > > Есть. Читаем RUP. И SADT заодно :) > > Ссылку на главу и раздел из RUP в студию!!! > У Новикова "Введение в RUP" Главы 8,9,10 "Деловое моделирование" (www.interface.ru) Глава 8. Диаграмма прецедентов. ...Диаграмма прецедентов показывает деловые субъекты, деловые прецеденты, пакеты деловых прецедентов и связи между ними. Никаких строгих правил относительно того, что нужно показывать в диаграммах прецедентов, не существует. Вы показываете те связи в модели, которые считаете интересными... Да здравствует методология RUP, самая методичная и логичная в мире! -- с уважением, Сергей Тарасов http://www.arbinada.com mailto:temp...@arbinada.com Автор: *"Serguei Tarassov" * Дата: *Tue, 5 Jun 2001 15:45:16 +0000 (UTC)* Местное время: *Вт. 5 июн 2001 16:45* Тема: *Re: моделирование бизнес-процессов* Доброго дня! "Max Belugin" wrote in message news: > Во-первых, UML - это не методика > Во-вторых, приведи альтернативы, которые тебе больше нравятся. Очень > интересуют методики (типа Catalysis) Методика чего? Для проектирования классов меня вполне этот кусок из UML устраивает. Для БД - ER-модель. Для бизнес-моделирования - IDEF. И все прекрасно сочетается. Альтернативы всему RUP? Оракловая CDM, ISO 12207, ГОСТ 34 и 20. У микрософта есть MSF. В каждой устоявшейся на рынке софтовой фирме есть свои отработанные производственные процессы. Ну и собственная голова, для начала, чтобы не уверовать в кумиров и панацею. -- с уважением, Сергей Тарасов http://www.arbinada.com mailto:temp...@arbinada.com Автор: *"Vladimir Pavlikov" * Дата: *Tue, 5 Jun 2001 15:51:21 +0000 (UTC)* Местное время: *Вт. 5 июн 2001 16:51* Тема: *Re: моделирование бизнес-процессов* Hello! "Lev Yunak" wrote: > > Я и говорю - не включенным в UML. Таких можно наделать сколько угодно, > > и уже делаются. А _одного_ - нет :( > Тебе человек дело предлагает. XMI уже есть и другого придумывать не надо. Мы же не мои проблемы решаем (справляюсь), речь о применимости uml. Именно его, а не чего-то еще. > Вон Серяков в mo.job.talk вообще крамолу сказал: "разработка - передача > понимания" :) Эта эха - рай для психиатров :) Не всвязи с Серяковым или конкретным высказыванием, в целом. -- Владимир Павликов. Отправлено через сервер Talk.Ru - http://www.talk.ru Автор: *"Vladimir Pavlikov" * Дата: *Tue, 5 Jun 2001 15:51:21 +0000 (UTC)* Местное время: *Вт. 5 июн 2001 16:51* Тема: *Re: моделирование бизнес-процессов* Hello! "Max Belugin" wrote: > Де факто XMI по-моему единственное текстовое представление от OMG. Или я > ошибаюсь? Возможно, не знаю. Отсюда вопрос - почему бы не реализовать модель именно на нем?, сняло бы много вопросов. > Okay. Я имел ввиду представление в объектной среде. С моей точки зрения > правильно работать через API (через DOM, а не через XML, через ADO, а не > через CSV). Оно не стандартизировано, но объектная модель для него есть. Если речь о стандартизованном API - никаких возражений. Т.е. DOM - куда ни шло, но никак не ADO - что с ним делать вне Винды? Да и - и то, и дру- гое - тормозуха, реализация паршивая :( > > Недостаточно детально? А есть ли вообще? Я могу составить огромный пере- > > чень, но нужен ли?, по моему, многое довольно очевидно. Может, попозже. > Я просил зоть одно для примера, иллюстрации. Для любого языка программирования есть транслятор, позволяющий получить диагностику формальной правильности и целостности. Если нет - средствами YACC даже для такого зверя, как C++ нарисую за пару дней - текст же. Для реализации юзкейса требуются... да, кстати - что именно _требуется_? Пусть как минимум, на самом формальном минимуме. И как мне провести проверку и получить диагностику. Желательно - не средствами розы или иного тула - что здесь рекомендует именно _язык_? > > При чем тут я? Текст, написанный на ANSI C, я могу успешно скомпилировать > > на нескольких десятках инструментов, как минимум. И реально использовал > > уже больше десятка. Потому, что речь идет о _языке_, а не о ... ладно :) > С объектами, написанными на любом языке под .NET можно работать на любом > другом, так как там стандартизирован runtimе - то есть набор понятий. Любой - это то ли 4, то ли 6, включая самые главные - Васик и несуществу- ющий покуда C#. Но не будем отвлекаться - при чем тут .NET? Его еще нет, а причинно-следственные связи никто не отменял. Да и не Виндой единой... > >Остальные не просто трудно - они нерешимы. > На практике решают. Стандарты есть. Неидеальны. Выше приведен требуемый пример. У меня их еще много... > А зачем вы вообще все это пишете? Наверное, у вас есть какие-то причины. Да я уже раза четыре ответил - был запрос _мнения_. Высказал, проиллюст- рировал... > А мне хотелось бы перейти от спора к рассмотрению конкретных недостатков UML. > Возможно, при этом рассмотрении можно перейти к способам минимизации их > последствий или их обходу. У меня нет желания спорить на эту тему. Не слишком интересно, да и со временем... :( Обход или минимизация недостатков реально нужного - это важно, но... Я таковым uml не считаю, а как рисовалка - сойдет, в отсут- ствие более приличного. -- Владимир Павликов. Автор: *"Serguei Tarassov" * Дата: *Tue, 5 Jun 2001 16:52:54 +0000 (UTC)* Местное время: *Вт. 5 июн 2001 17:52* Тема: *Re: моделирование бизнес-процессов* Доброго дня! "Lev Yunak" wrote in message news: [skip] > Это не пример. Дайте конкретный пример - тот же пресловутый заказ > авиабилетов например. О, кажется нашел готовый примерчик "Оприходование товара на складе предприятия от продавца". http://www.interface.ru/fset.asp?Url=/misc/uml1.htm Авторы заявляют о своем большом опыте подобного рисования разных заказчиков с натуры. Явные глобальные недостатки: 1. Ориентация на описание "как есть". 2. Нет связи с другими моделями, то есть непонятно даже, является ли документ (объект) внутренним или межсистемным. Непонятно, например, также почему именно кладовщик, а не уборщица и курьер по совместительству, должен совершить операцию "Передает экземпляр акта в бухгалтерию". 3. Ориентация на структуру, а не на процессы - это будет в итоге программка, прожившая до первой реорганизации в отделе. Именно процессы, то есть бизнес-функции выявляют необходимость в тех или иных отделов и исполнителей (объектов). 4. Хочется сказать "Check model", а не имею возможности :-(( Вот решат менеджеры упростить процедуру и отменить выписку акта - вся диаграмма идет в RecycleBin. Но это не беда, вот непонятно, как это отразится на всей модели в целом... 5. Надо использовать 3 (!) слабосвязанные нотации (деятельности, прецеденты и последовательности)... Явные локальные беды: 1. Входящий документ отличается от исходящего фиолетовым цветом (рис.7). Картинка может и красивая, но семантически бесполезная. Особенно, если в другом отделе художники из соседней внедренческой фирмы рисуют зеленым цветом. 2. Там же (рис.7) приемный акт выписывается в 2 экземплярах. Показан только 1, непонятно, зачем нужны 2, сразу непонятно, куда идут оба - это вдруг обнаруживается на рис.10, но по-прежнему не понятно, зачем нужно 2, а не 1, но последовательно переданный от снабженца к бухгалтеру. Модель не отвечает на вопросы элементарного анализа бизнес-процессов, следовательно, по определению модели из SADT, эти картинки моделью не являются. -- с уважением, Сергей Тарасов http://www.arbinada.com mailto:temp...@arbinada.com Автор: *"Lev Yunak" * Дата: *Wed, 6 Jun 2001 06:09:24 +0000 (UTC)* Местное время: *Ср. 6 июн 2001 07:09* Тема: *Re: моделирование бизнес-процессов* Serguei Tarassov сообщил в новостях следующее: > > Так и есть - необходимо и достаточно. Ну не ужели вы думаете, > > что в rational дураки работают? > Веский аргумент... Пища для размышления. > Еще раз предлагаю описать несложную модель в IDEF0 и на прецедентах. И > оценить информативность модели. Так. На попятную идешь. То говоришь невозможно реализовать, то про информативность заговорил. > > Это не пример. Дайте конкретный пример - тот же пресловутый заказ > > авиабилетов например. > Например, отгрузка товара со склада. Итак, у тебя не получилось описать эту задачку на UML? Какие были трудности? > > > Попробуй то же описать, используя только одну нотацию из набора UML. > > Я вас не ограничиваю в IDEF, а вы меня не ограничивайте в UML > См.выше... Ну сам посуди. Давай ты будешь программировать на Си без логических операторов, а я буду на Паскале без оператора присвоения. И что у нас получится? > Как определить масштаб модели в UML? В левом нижнем углу диаграммы можно написать "M 1:1" :-) Что значит масштаб модели? > > > > Есть преобразование в C++, java, .... > > > Вот вот. Значит изначально они не были формализованы, поэтому о методологии > > > речи идти не может. > > Оракл, C++... это уже реализация. Существет слишком много реализаций, чтобы > > их заносить в методику проектирования. В IDEF этого тоже нет. И это правильно. > А в диаграмме классов есть... > > > > > RUP - неправильный ответ, там нет ответа > > > > > на вопрос "Как моделировать на UML". > > У Новикова "Введение в RUP" Главы 8,9,10 "Деловое моделирование" > ...Диаграмма прецедентов показывает деловые субъекты, деловые > прецеденты, пакеты деловых прецедентов и связи между ними. > Никаких строгих правил относительно того, что нужно показывать в диаграммах > прецедентов, не существует. Вы показываете те связи в модели, которые считаете интересными... > Да здравствует методология RUP, самая методичная и логичная в мире! Чут-чуть не дочитали. Начиная со страницы 8-21 и далее в главах 9 и 10 - последовательность действий при моделировании. Автор: *"Lev Yunak" * Дата: *Wed, 6 Jun 2001 06:36:50 +0000 (UTC)* Местное время: *Ср. 6 июн 2001 07:36* Тема: *Re: моделирование бизнес-процессов* Vladimir Pavlikov сообщил в новостях следующее: > > > Я и говорю - не включенным в UML. Таких можно наделать сколько угодно, > > > и уже делаются. А _одного_ - нет :( > > Тебе человек дело предлагает. XMI уже есть и другого придумывать не надо. > Мы же не мои проблемы решаем (справляюсь), речь о применимости uml. Именно > его, а не чего-то еще. Как-бы народ уже в тихую использует и никому не говорит :) Вообще анализируя последние технологии в программной инженерии можно заметить некоторую перестройку - как-то все более четко становится. Помню свои сомнения еще несколько лет. Каждый продукт нес с собой свою технологию как разработки так и организации процесса разработки. Сейчас внутри продуктов функциональные части, а также сама организация разработки более четки и отделены друг от друга. Я думаю, что главным вопросом в совершенствовании своего процесса разработки нужно считать вопрос "Куда идешь?" (QUO VIDIS?) Автор: *"Max Belugin" * Дата: *Wed, 6 Jun 2001 07:30:01 +0000 (UTC)* Местное время: *Ср. 6 июн 2001 08:30* Тема: *Re: моделирование бизнес-процессов* > > Де факто XMI по-моему единственное текстовое представление от OMG. Или я > > ошибаюсь? > Возможно, не знаю. Отсюда вопрос - почему бы не реализовать модель > именно на нем?, сняло бы много вопросов. Какое вам дело до того, как оно реализовано - вам же нужен текстовый интерфейс к модели. Какая вам разница в чем он хранит? - у вас есть возможность импорта - экспорта. Кстати, ArgoUML хранить в XMI. (да в стандарт это требование не входит) > > Okay. Я имел ввиду представление в объектной среде. С моей точки зрения > > правильно работать через API (через DOM, а не через XML, через ADO, а не > > через CSV). Оно не стандартизировано, но объектная модель для него есть. > Если речь о стандартизованном API - никаких возражений. Т.е. DOM - куда > ни шло, но никак не ADO - что с ним делать вне Винды? Да и - и то, и дру- > гое - тормозуха, реализация паршивая :( Согласен. DOM - оъектная модель <--> UML metamodel > > > Недостаточно детально? А есть ли вообще? Я могу составить огромный пере- > > > чень, но нужен ли?, по моему, многое довольно очевидно. Может, попозже. > > Я просил зоть одно для примера, иллюстрации. > Для любого языка программирования есть транслятор, позволяющий получить > диагностику формальной правильности и целостности. Если нет - средствами > YACC даже для такого зверя, как C++ нарисую за пару дней - текст же. > Для реализации юзкейса требуются...да, кстати - что именно _требуется_? > Пусть как минимум, на самом формальном минимуме. И как мне провести проверку > и получить диагностику. Желательно - не средствами розы или иного тула - > что здесь рекомендует именно _язык_? Насколько я понимаю, вы имеете ввиду проверку синтаксиса. Для UML это не нужно, так как то что реализует метамодель уже синтаксически правильно. Что такое ЮзКейз там описано. > > > При чем тут я? Текст, написанный на ANSI C, я могу успешно скомпилировать > > > на нескольких десятках инструментов, как минимум. И реально использовал > > > уже больше десятка. Потому, что речь идет о _языке_, а не о ... ладно :) > > С объектами, написанными на любом языке под .NET можно работать на любом > > другом, так как там стандартизирован runtimе - то есть набор понятий. > Любой - это то ли 4, то ли 6, включая самые главные - Васик и несуществу- > ющий покуда C#. Но не будем отвлекаться - при чем тут .NET? Его еще нет, > а причинно-следственные связи никто не отменял. Да и не Виндой единой... Мы про стандарты или про реализации? По-моему Common Runtime стандартизируется независимо от Microsoft. > Да я уже раза четыре ответил - был запрос _мнения_. Высказал, проиллюст- > рировал... Извините, был невнимателен. > > А мне хотелось бы перейти от спора к рассмотрению конкретных недостатков > > UML. > > Возможно, при этом рассмотрении можно перейти к способам минимизации их > > последствий или их обходу. > У меня нет желания спорить на эту тему. Не слишком интересно, да и со > временем... :( Обход или минимизация недостатков реально нужного - это > важно, но... Я таковым uml не считаю, а как рисовалка - сойдет, в отсут- > ствие более приличного. Разойдемся. -- Отправлено через сервер Talk.Ru - http://www.talk.ru Автор: *"Ilya Zvyagin" * Дата: *Wed, 6 Jun 2001 08:30:05 +0000 (UTC)* Местное время: *Ср. 6 июн 2001 09:30* Тема: *Re: моделирование бизнес-процессов* Vladimir Pavlikov wrote in message >На русском не знаю, стоимость нужно конкретно запрашивать, остальное - на >www.togethersoft.com . Только учти - ему 256 Мег мало :) А что, Розе что ли много ? :-) Автор: *"Vladimir Pavlikov" * Дата: *Wed, 6 Jun 2001 10:48:50 +0000 (UTC)* Местное время: *Ср. 6 июн 2001 11:48* Тема: *Re: моделирование бизнес-процессов* Hello! "Lev Yunak" wrote: > Вообще анализируя последние технологии в программной инженерии можно > заметить > некоторую перестройку - как-то все более четко становится. > Помню свои сомнения еще несколько лет. Каждый продукт нес с собой свою > технологию как разработки так и организации процесса разработки. > Сейчас внутри продуктов функциональные части, а также сама организация > разработки более четки и отделены друг от друга. Никаких возражений. Разница лишь в одном - я считаю, что пока имеем блин даже не комом, а колом. Сама же тенденция обнадеживает, но как-то слишком поздно начинается, неудачно и медленно :( -- Владимир Павликов. Автор: *"Vladimir Pavlikov" * Дата: *Wed, 6 Jun 2001 11:19:01 +0000 (UTC)* Местное время: *Ср. 6 июн 2001 12:19* Тема: *Re: моделирование бизнес-процессов* Hello! "Max Belugin" wrote: > > > Де факто XMI по-моему единственное текстовое представление от OMG. Или я > > > ошибаюсь? > > Возможно, не знаю. Отсюда вопрос - почему бы не реализовать модель > > именно на нем?, сняло бы много вопросов. > Какое вам дело до того, как оно реализовано - вам же нужен текстовый > интерфейс к модели. Нужен. Но его нет. > Какая вам разница в чем он хранит? - у вас есть возможность импорта - > экспорта. Три раза "нет". 1. У меня нет этой возможности, в смысле - uml не гарантирует (не требует). 2. Я (пока) не знаю инструментов, позволяющих мне полноценно использовать это представление. Если бы оно было обязательным, они бы наверняка появи- лись, но оно необязательно... 3. Импорта/экспорта категорически недостаточно, ибо это лишь статические срезы. Я не зря уже не раз упоминал тут together - этот продукт работает с _исходными текстами_ (в части, юзкейсов не касающейся, естественно), и любые изменения (в тексте ли, в диаграммах ли) отражаются в оставшейся части сразу. Но - чудес на свете не бывает, и язык программирования не может описывать бОльшую часть модели, тем более - взаимосвязи этих част- тей. А вот язык моделирования - мог бы, если бы существовал... > > Для любого языка программирования есть транслятор, позволяющий получить > > диагностику формальной правильности и целостности. Если нет - средствами > > YACC даже для такого зверя, как C++ нарисую за пару дней - текст же. > > Для реализации юзкейса требуются...да, кстати - что именно _требуется_? > > Пусть как минимум, на самом формальном минимуме. И как мне провести проверку > > и получить диагностику. Желательно - не средствами розы или иного тула - > > что здесь рекомендует именно _язык_? > Насколько я понимаю, вы имеете ввиду проверку синтаксиса. Для UML это не > нужно, так как то что реализует метамодель уже синтаксически правильно. Что > такое ЮзКейз там описано. Не только, и не столько синтаксис. Могу я узнать, сколько классов (и каких) в данный момент живут без диаграмм состояний? Количество юзкейсов с непол- ностью определенной или вообще отсутствующей реализацией? Классов, которые не "приписаны" ни к одному модулю комплекта поставки, т.е. болтаются в воз- духе? Речь же о модели, _взаимосвязанной_, а не о кучке картинок. Это нужно не uml (ему вообще ничего не нужно), это нужно мне и многим другим. > Мы про стандарты или про реализации? По-моему Common Runtime > стандартизируется независимо от Microsoft. По моему, .NET - это именно Microsoft. И не имеет никакого отношения к UML. > Разойдемся. Ok. -- Владимир Павликов. Отправлено через сервер Talk.Ru - http://www.talk.ru Автор: *"Vladimir Pavlikov" * Дата: *Wed, 6 Jun 2001 11:19:02 +0000 (UTC)* Местное время: *Ср. 6 июн 2001 12:19* Тема: *Re: моделирование бизнес-процессов* Hello! "Ilya Zvyagin" wrote: > >На русском не знаю, стоимость нужно конкретно запрашивать, остальное - на > >www.togethersoft.com. Только учти - ему 256 Мег мало :) > А что, Розе что ли много ? Памяти, как и денег, много не бывает. Но на розе я работаю на 128. На этой памяти на тугезу можно только любоваться :) Разумеется, речь о явовской. Была сишная реализация, несравнимо более подвижная, но она уже не развивается :( -- Владимир Павликов. Отправлено через сервер Talk.Ru - http://www.talk.ru Автор: *"Max Belugin" * Дата: *Wed, 6 Jun 2001 11:57:44 +0000 (UTC)* Местное время: *Ср. 6 июн 2001 12:57* Тема: *Re: моделирование бизнес-процессов* > Не только, и не столько синтаксис. Могу я узнать, сколько классов (и каких) > в данный момент живут без диаграмм состояний? Количество юзкейсов с непол- > ностью определенной или вообще отсутствующей реализацией? Классов, которые > не "приписаны" ни к одному модулю комплекта поставки, т.е. болтаются в воз- > духе? Речь же о модели, _взаимосвязанной_, а не о кучке картинок. > Это нужно не uml (ему вообще ничего не нужно), это нужно мне и многим другим. В сторону: Все это запросы над метамоделью. Текст не нужен. Единственное препятствие - отсутствие реализации декларативного языка запросов над объектами в большинстве объектных сред. (напрмер OQL). Все это операции не с текстом, а с моделью. По-хорошему надо бы реализовать биндинги метамодели модели на популярные объектные модели, а затем реализовать инструменты работающие над ними. Все это решалось бы простыми запросами чего-нибудь типа OQL. Единственное, зачем нужно преобразовывать в текст - для обмена с другими инструментами и для работы всего что работает с текстом (типа grep), но с моей точки зрения это ограничено полезно. В доработке нуждаются API и объектные среды. Это будет полезнее. -- Отправлено через сервер Talk.Ru - http://www.talk.ru Автор: *"Vladimir Pavlikov" * Дата: *Wed, 6 Jun 2001 12:38:24 +0000 (UTC)* Местное время: *Ср. 6 июн 2001 13:38* Тема: *Re: моделирование бизнес-процессов* Hello! "Max Belugin" wrote: > В сторону: > Все это запросы над метамоделью. Текст не нужен. Единственное препятствие - > отсутствие реализации декларативного языка запросов над объектами в > большинстве объектных сред. (напрмер OQL). > Все это операции не с текстом, а с моделью. По-хорошему надо бы реализовать > биндинги метамодели модели на популярные объектные модели, а затем > реализовать инструменты работающие над ними. Все это решалось бы простыми > запросами чего-нибудь типа OQL. Почему в сторону - вполне по делу. Я на тексте в общем-то не наста- иваю. Но - потребуется QQL... А я ведь могу и еще немало подкинуть, из других классов --> еще что-то потребуется. А с текстом _уже_ работает огромное количество инструментов, и можно самому печь, как блины. Т.е. не необходимо, но - нужны веские основания для работы не с текстом. > Единственное, зачем нужно преобразовывать в текст - для обмена с другими > инструментами и для работы всего что работает с текстом (типа grep), но с > моей точки зрения это ограничено полезно. Ты модель, после "выгрузки" и минимальной редакции средствами прог- раммирования обратно импортируешь? "И так 200 раз подряд" - зачем? А если нет - правишь руками (выполняя двойную работу с риском рассогласования) либо так и оставляешь модель неадекватной? > В доработке нуждаются API и объектные среды. Это будет полезнее. Это другой вопрос. Ничуть не возражая, замечу, что к теме отношения не имеет. Разве что - либо этот вопрос решается на уровне стандарта языка/методологии/технологии (в идеале - до появления инструментов) либо - "хотели как лучше, получилось как всегда" - примеров "похожего, но разного" миллион. И несовместимого, естественно. Это дает кучу новых рабочих мест, но совершенно не радует. -- Владимир Павликов. Отправлено через сервер Talk.Ru - http://www.talk.ru Автор: *"Max Belugin" * Дата: *Wed, 6 Jun 2001 13:27:26 +0000 (UTC)* Местное время: *Ср. 6 июн 2001 14:27* Тема: *Re: моделирование бизнес-процессов* > Почему в сторону - вполне по делу. Я на тексте в общем-то не наста- > иваю. Но - потребуется QQL... А я ведь могу и еще немало подкинуть, > из других классов --> еще что-то потребуется. А с текстом _уже_ > работает огромное количество инструментов, и можно самому печь, как > блины. Т.е. не необходимо, но - нужны веские основания для работы > не с текстом. Дело в том, что с текстом, представляющим модлеь можно сделать очень мало осмысленных операций. То, что вы хотите сделать, проще сделать при помощи модели, а не текста ее представляющего. При работе с исходникми приходится ухищряться: для того, чтобы, например переименовать какой-нибудь класс Name в класс MyName недостаточно найти слово Name и заменить его на MyName - надо еще знасть в каком контексте это слово употребляется (напрмер, не часть ли оно строковой константы). С другой стороны, в терминах объектной модели этот запрос тривиален. Model.Classes.byName('Name').Name='MyName' > > Единственное, зачем нужно преобразовывать в текст - для обмена с другими > > инструментами и для работы всего что работает с текстом (типа grep), но с > > моей точки зрения это ограничено полезно. > Ты модель, после "выгрузки" и минимальной редакции средствами прог- > раммирования обратно импортируешь? "И так 200 раз подряд" - зачем? > А если нет - правишь руками (выполняя двойную работу с риском > рассогласования) либо так и оставляешь модель неадекватной? Текст меня до сих пор не интересовал. Исходники я синхронизирую с моделью. В любом случае никто не мешат делать это пакетно. Еще никто не мешает делать это на лету. Кстати, VAJ, насолько я поню работает так даже с явскими исходниками. > Это другой вопрос. Ничуть не возражая, замечу, что к теме отношения > не имеет. Разве что - либо этот вопрос решается на уровне стандарта > языка/методологии/технологии (в идеале - до появления инструментов) > либо - "хотели как лучше, получилось как всегда" - примеров "похожего, > но разного" миллион. И несовместимого, естественно. Это дает кучу > новых рабочих мест, но совершенно не радует. В общем, ваше мнение не то что UML "не язык", а то, что UML - язык, сформулированный иероглифами, которые не приспособлены для машинного понимания? -- Отправлено через сервер Talk.Ru - http://www.talk.ru Автор: *"Vladimir Pavlikov" * Дата: *Wed, 6 Jun 2001 15:12:59 +0000 (UTC)* Местное время: *Ср. 6 июн 2001 16:12* Тема: *Re: моделирование бизнес-процессов* Hello! "Max Belugin" wrote: > Дело в том, что с текстом, представляющим модлеь можно сделать очень мало > осмысленных операций. > То, что вы хотите сделать, проще сделать при помощи модели, а не текста ее > представляющего. Ты упорно противопоставляешь модель представлению. Но что есть модель вне представлений? В действительности, как я понимаю, ты имеешь ввиду некое нетекстовое представление. Визуальное представление диаграмм вижу, модели - не вижу никакого. Тем более не вижу, что осмысленного можно сделать с картинками. В чем я неправ? > При работе с исходникми приходится ухищряться: для того, чтобы, например > переименовать > какой-нибудь класс Name в класс MyName недостаточно найти слово Name и > заменить его на MyName - надо еще знасть в каком контексте это слово > употребляется (напрмер, не часть ли оно строковой константы). С другой > стороны, в терминах объектной модели этот запрос тривиален. > Model.Classes.byName('Name').Name='MyName' Последняя строка - не текст??! Я нигде не говорил о plain-тексте, подоб- ному сорцам языков программирования. Хотя - в старых бейсиках реальное хранение было в каком-то бинарном формате, текст показывался лишь в ре- дакторе. И это никого не волновало - тул обеспечивал взаимооднозначное соответствие сам. Автоматом, в фоне. Пожалуйста, храните хоть в sql-базе, нет проблем. Только дайте схему, с описанием и серверной логикой (триггеры, системные СП, констрейны), на уровне _стандарта_. Короче - дайте хоть что-то. Но - полноценное! Модельное. А не отдельные куски, для которых стандартизован лишь внешний вид _отдельных элементов_. > Текст меня до сих пор не интересовал. Исходники я синхронизирую с моделью. > В любом случае никто не мешат делать это пакетно. Еще никто не мешает делать > это на лету. Исходники - это просто пример. С ними - да, можно синхронизироватся пакетно. Я говорю о работе с самой моделью. > Кстати, VAJ, насолько я поню работает так даже с явскими исходниками. VAJ и Together - с явой (последний и с С++), кто-то еще с кем-то. А UML? > В общем, ваше мнение не то что UML "не язык", а то, что UML - язык, > сформулированный иероглифами, которые не приспособлены для машинного > понимания? Видимо, мы по разному трактуем слово "модель". Для меня это взаимосвязанная система представлений с разных точек зрения (от целей до реализаций и сетапов), представляющая _единое целое_. Ничего, описывающего данное "определение", нет ни в каком виде вообще, ни у одного тула. И уж тем более нет такого языка, ни в каком виде. UML - еще одна широко раскру- ченная терминологическая пустышка, вроде явы. Хотя последняя и имеет собственную фичу (одну) - независимость от платформы. Почти как Forth :) А UML не имеет ничего... Подчеркиваю - это просто мое мнение. У меня нет желания доказывать свою правоту. Могу лишь констатировать, что [пока] не то что опровергнуть - посеять сомнение не удалось никому. Не по причине моей упертости - обратный процесс виден отчетливо. -- Владимир Павликов. Отправлено через сервер Talk.Ru - http://www.talk.ru Автор: *"Max Belugin" * Дата: *Thu, 7 Jun 2001 11:18:47 +0000 (UTC)* Местное время: *Чт. 7 июн 2001 12:18* Тема: *Re: моделирование бизнес-процессов* > Ты упорно противопоставляешь модель представлению. Но что есть модель > вне представлений? В действительности, как я понимаю, ты имеешь ввиду > некое нетекстовое представление. Визуальное представление диаграмм > вижу, модели - не вижу никакого. Тем более не вижу, что осмысленного > можно сделать с картинками. В чем я неправ? Я имею ввиду представление модели в объектной среде. В виде объектно-ориентиррованного API. Например, XML есть текстовое представление DOM, а для JDBC вообще нет текстового предсталения. Ну в общем, как это обычно делается в трехзвенных приложениях представление-бизнес логика-хранение. Если вы что-т хотите сделать программно с существующим приложением, вы ведь работаете через его API, а не через текстовое представление? > Пожалуйста, храните хоть в sql-базе, нет проблем. Только дайте схему, > с описанием и серверной логикой (триггеры, системные СП, констрейны), > на уровне _стандарта_. Короче - дайте хоть что-то. Но - полноценное! > Модельное. А не отдельные куски, для которых стандартизован лишь > внешний вид _отдельных элементов_. Схема есть!!! Она входит в стандарт!!! Вы читали UML Semantics guide?! Там схемки, описывающие понятия UML на самом UML. Почти как SQL база данных, только объекты :). -- Отправлено через сервер Talk.Ru - http://www.talk.ru Автор: *"Lev Yunak" * Дата: *Thu, 7 Jun 2001 11:39:08 +0000 (UTC)* Местное время: *Чт. 7 июн 2001 12:39* Тема: *Re: моделирование бизнес-процессов* > Схема есть!!! Она входит в стандарт!!! Вы читали UML Semantics guide?! Там > схемки, описывающие понятия UML на самом UML. Почти как SQL база данных, > только объекты :). Кстати, это показатель продуманности. Язык - это то, что может описать само себя. Автор: *"Vladimir Pavlikov" * Дата: *Thu, 7 Jun 2001 13:00:56 +0000 (UTC)* Местное время: *Чт. 7 июн 2001 14:00* Тема: *Re: моделирование бизнес-процессов* Hello! "Max Belugin" wrote: > > Ты упорно противопоставляешь модель представлению. Но что есть модель > > вне представлений? В действительности, как я понимаю, ты имеешь ввиду > > некое нетекстовое представление. Визуальное представление диаграмм > > вижу, модели - не вижу никакого. Тем более не вижу, что осмысленного > > можно сделать с картинками. В чем я неправ? > Я имею ввиду представление модели в объектной среде. В виде > объектно-ориентиррованного API. Я уже на все согласен - где мне получить _uml_ api? > > Пожалуйста, храните хоть в sql-базе, нет проблем. Только дайте схему, > > с описанием и серверной логикой (триггеры, системные СП, констрейны), > > на уровне _стандарта_. Короче - дайте хоть что-то. Но - полноценное! > > Модельное. А не отдельные куски, для которых стандартизован лишь > > внешний вид _отдельных элементов_. > Схема есть!!! Она входит в стандарт!!! Вы читали UML Semantics guide?! Там > схемки, описывающие понятия UML на самом UML. Почти как SQL база данных, > только объекты :). Зачем же так возбуждаться? :) Разумеется, чтобы что-то утверждать, требуется иметь представление. Поэтому читать пришлось много, и вывод не на пустом месте. Вот только SQL базы данных недостаточно - для работы с ней нужен сам sql. Да ты и сам пишешь "схемки, описываю- щие ... понятия". Отдельные понятия - это слова, а не язык. Да и работать со схемками... С этим справился человеческий интеллект, ну да он с чем угодно справится. А вот как сделать автоматический тул? Я просил схему sql-базы, хранящей (любое) представление модели, если бы таковая существовала. Но - СТАНДАРТНОЙ! А не "схемки" - у меня их навалом, в полутора десятках документов... Признаться, не понимаю причин такого неприятия. Я уже довольно много перечислил вещей, которые хотелось бы иметь. И каковые есть для любого языка, если речь идет о языке, а не о "языке". Неважно, текстовом или каком другом. Вместо демонстрации того, что это (хоть что-то) возможно - только uml-средствами, а не розой-тугезой и т.д. мне рассказывают про схемки. И что? -- Владимир Павликов. Отправлено через сервер Talk.Ru - http://www.talk.ru Автор: *"Max Belugin" * Дата: *Fri, 8 Jun 2001 10:35:50 +0000 (UTC)* Местное время: *Пт. 8 июн 2001 11:35* Тема: *Re: моделирование бизнес-процессов* > > Я имею ввиду представление модели в объектной среде. В виде > > объектно-ориентиррованного API. > Я уже на все согласен - где мне получить _uml_ api? А! Уговорил все-таки! Нету! Но для того, чтоб было достаточно описать отображение UML на популярные объектные среды (кстати, есть ли стандартизованные?). В любом случае недостаток - отсутствие АПИ, а не ненавязывание текстового представления. > > > Пожалуйста, храните хоть в sql-базе, нет проблем. Только дайте схему, > > Схема есть!!! Она входит в стандарт!!! Вы читали UML Semantics guide?! Там > > схемки, описывающие понятия UML на самом UML. Почти как SQL база данных, > > только объекты :). > Зачем же так возбуждаться? :) А зачем вы возбуждаете? :) >Разумеется, чтобы что-то утверждать, > требуется иметь представление. Далеко не всем это разумеется.... >Поэтому читать пришлось много, и вывод > не на пустом месте. Вот только SQL базы данных недостаточно - для > работы с ней нужен сам sql. Роль DML исполняет OCL + динамические диаграммы >Да ты и сам пишешь "схемки, описываю- > щие ... понятия". Отдельные понятия - это слова, а не язык. Да и > работать со схемками... С этим справился человеческий интеллект, ну > да он с чем угодно справится. А вот как сделать автоматический тул? Ваш автоматический тул в любом случае будет работать с какой-то метамоделью (моедлью вашей модели) только если входом будет текстовый файл, его придется разбирать для того чтобы преобразовать к метамодели. > Я просил схему sql-базы, хранящей (любое) представление модели, если > бы таковая существовала. Но - СТАНДАРТНОЙ! А не "схемки" - у меня их > навалом, в полутора десятках документов... Непонимаю: с моей точки зрения осталось только стандартизировать отображение модели на популярные объектные среды. >Неважно, текстовом или > каком другом. Вместо демонстрации того, что это (хоть что-то) возможно > - только uml-средствами, а не розой-тугезой и т.д. мне рассказывают > про схемки. И что? Непонимаю: все равно, что сказать "все это делается при помощи конкретных компиляторов, а как мне это сделать с помощью C" -- Отправлено через сервер Talk.Ru - http://www.talk.ru