Мудрая белкаДобрый день.
Стоит задача моделировать логику процесса в любом из средств моделирования (последовательность выполняемых сущностей и условия переходов между ними), а затем экспортировать всю эту логику в неком стандартизироавнном формате (XML например, или что-то еще), чтоб обрабатывать "нарисованную логику" в самописном "движке". Здесь интересует не столько средство моделирования (понятно, что их десятки), а возможность "понятного" экспорта нарисованной логики.
Подскажите пжт, может кто сталкивался с подобными задачами, буду очень благодарен.
Сталкивался. Если речь идет не о станках с ЧПУ или создании завода-автомата, "моделировать логику процесса" - пустая трата времени, так как этот процесс - процесс управления данными. Нужно данные моделировать:)

Мудрая белкаНужна именно модель бизнес-процесса, а не данных. Данные - это совсем другой уровень абстракции. С данными работа идет в конкретно взятых сущностях, но не на этом уровне.
Ошибаетесь. Это именно тот уровень абстракции. Бизнес-процесс - это процесс управления данными. "Работа с данными" не может "идти в сущностях":)

474БредятинаОшибаетесь. Это именно тот уровень абстракции. Бизнес-процесс - это процесс управления данными. "Работа с данными" не может "идти в сущностях":)
Как название бизнес-процесса "процессом управления данными" избавляет от необходимости описывать логику работы с данными? Промоделировав данные вы разве волшебным образом получите и описание действий с ними?
Разумеется. Это органичная часть именно моделирования данных.

Роман ДынникБредятина"моделировать логику процесса" - пустая трата времени, так как этот процесс - процесс управления данными. Нужно данные моделировать:)
Бредятина,
Вы почему то в своих постах упорно не хотите разделять структуру данных и поведение, смешиваете все в одну кучу - моделирование данных и поведение (диаграммы потоков данных, диаграммы бизнес-процессов)
А Вы упорно не хотите понимать, что я не смешиваю все в кучу, а поясняю суть:)
Роман ДынникМудрая белкаЗдесь интересует не столько средство моделирования (понятно, что их десятки), а возможность "понятного" экспорта нарисованной логики.
Здесь Вам стоит посмотреть на подходы и стандарты.
Например, MDA от OMG вводит понятие Platform independent model и Platform specific model.
Конечное MDA-приложение состоит из PIM + одной или нескольких PSM для конкретной платформы.
Применительно к моделированию бизнес-процессов - BPMN - независимая от платформы графическая нотация поддерживаемая большинством продуктов моделирования бизнес-процессов.
Далее ряд средств позволяют получить BPEL из BPMN. BPEL - это xml-стандарт, который уже ближе к конкретной платформе и BPM-продукты разных вендоров реализуют его поддержку у себя.

Я сделал вывод в том числе и после углубленного изучения перечисленных Вами типов продуктов и технологий:) Конечно, можно просто прислушаться к местным "специалистам" и игнорировать результаты объективного анализа и, соответственно, все мои сообщения:)

olap4ikДа не слушайте вы эту Бредятину. Посмотрите другие топики, разве не понятно что троль?
Закопался в Дейте и пытается цитировать его, при чем часто сам либо плохо понимает его, либо притягивает написанное за уши.
Просто игнорируйте и все.
Вы не правильно, мне кажется понимаете, это связку - бизнес-процессов с данными. Судя по необоснованной критике Дейта. Это простительно, конечно, для студента, но просто будьте повнимательнее в следующий раз:)

Роман ДынникБредятинаЯ сделал вывод в том числе и после углубленного изучения перечисленных Вами типов продуктов и технологий:) Конечно, можно просто прислушаться к местным "специалистам" и игнорировать результаты объективного анализа и, соответственно, все мои сообщения:)
За час углубленно изучить все перечисленное мной невозможно в принципе, так что словосочетание "объективный анализ" здесь мягко говоря неуместно и вызывает большие сомнения.
Глупость. Извините, но я вынужден быть объективным:) Не за час, а за примерно три года. Для меня этого достаточно, когда речь идет о какой-либо технологии. Но от таких, как Вы, извинений не дождешься, конечно же:) Только бана:)

Роман ДынникБредятинаА Вы упорно не хотите понимать, что я не смешиваю все в кучу, а поясняю суть:)

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

Роман ДынникБредятинаА я вот прямо сейчас использую систему федерального уровня, сделанную "от процессов" вместо "от данных".
Ни одна методология разработки ПО (RUP, MSF, CMMI), и ни один архитетурный фреймворк, такие как Zahman, TOGAF не ставят во главу угла "проектирование от процессов" или "проектирование от данных", и даже не вводят таких терминов, насколько я помню.
Центральным элементом являются требования, анализируя которые параллельно создаются модели данных и модели процессов (возможно, возможно даже разными людьми), между которыми в последствии осуществляется маппинг.
Показательно, что в Software Architecture Document и в Documenting Software Architectures: Views and Beyond, Second Edition также введены разделы(диаграммы) отражающие то, как процессы и данные мапятся. Но повторюсь, нигде "проектирование от процессов" или "проектирование от данных" не ставится выше или до(после) или вместе, к тому же они как правило отражают view различных shareholder-ов.
Я использую эти термины, что более выпукло показать проблему.
Абсолютно ущербная технология: "между которыми в последствии осуществляется маппинг".
Все требования должны быть отражены в модели данных. Все что происходит между insert, update и delete должно быть отражено в модели данных (разумеется во втором смысле по Дейту), а не каким-то другим человеком где-то в другом месте.

Роман ДынникАбсолютно ущербной технологией можно назвать попытку запихнуть все в одну модель, она равносильна попытке запихнуть всю модель данных в одну сущность.

Это неверная аналогия. Что всё? Всё - это данные:)

Роман ДынникКроме того технологии, методологии, архитектурные фреймворки, которые Вы называли ущербными разрабатываются целыми институтами, группами и применяются на государственном уровне.

Пожалуйста, говорите по существу вопроса. Вы как президент говорите: "раз ЕГЭ применяется в развитых странах, то это хорошая технология":)
Как будто я виноват в том, что целые институты и группы разрабатывают ущербные технологии.
Роман ДынникА о Вас я ничего не слышал, равно как и о Ваших трудах.
Поэтому, эти самые на Ваш взгляд "ущербные технологии" в праве вызывать гораздо большее доверие, чем чьи-либо личные и спорные трактовки Дейта.

Разумеется. Ни слова по существу - закон форума:) Какие спорные? Неужели все еще спорные?:)

Роман Дынник Бредятина,
Какие спорные? Неужели все еще спорные?:)
Спорный не Дейт, а Ваши трактовки Дейта, выдернутые из контекста.

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

Это не по существу. Это политическое существо, точнее. Практики применения, практически всегда, безуспешны, так как технологии ориентации на бизнес-процессы (учитывая, что бизнес-процесс - это процесс управления данными) фундаментально ошибочны.
Роман ДынникПриведите ссылки на свои "труды" и, возможно, разговор примет более конструктивное русло и с большим количеством участников.
Пока же налицо что Вы не понимаете или не знаете даже основ SADT, принципов декомпозиции, не разделяете структурные и поведенческие модели.
Отсюда Ваше стремление хаить чужой труд.
Я досконально знаком не только с основами, но с мельчайшими деталями, и ничего не хаю.
А Вы по-прежнему ведете себя по-хамски, так как по-существу Вам сказать нечего.
Роман ДынникОтсюда же и от недостатка практик - незнание и непонимание основных архитектурных принципов (масштбирования, слабой связности, отказоустойчивости...) и, как следствие, стремление свести всё к данным и одной модели. Такой проектировщик принесет гораздо больший урон проекту, чем тот который "проектирует от данных" или "от процессов", потому что создаст монолитную неуправляемую архитектуру, да и еще и спихнет абсолютно все в хранилище.
Так, так, но конкретно-то что Вы имеет в виду??? Какой проектировщик??? Давайте что-нибудь с Вами спроектируем:) Поясните на любом примере о чем ы говорите???
Роман ДынникВы так любите обращаться ко многим участникам со словом "студент", но поговорить то с Вами по-большому счету не о чем кроме ER-моделировния, поэтому студентом на самом деле стоит назвать Вас.
Я здесь и дибил, и придурок, и еще бог знает кто))) Побыть еще и студентом я не против, если вопросы будут обсуждаться по существу. А от Вас, видимо, менеджера (теперь правильно?:)), по существу трудно добиться:) Вы уж лучше ничего на форуме не пишите, толку никакого.