Проектирование: Альтернатива IDEF0 #236412

Создал тут ветку по поводу книг, так ее уже утащили, а я как раз спросить хотел: Если IDEF0 - устарела, то что использовать, что используете вы?

кто куда её утащил? ветка вполне живая. В принципе можно продолжить общение в той ветке

Сейчас модно использовать UML

Не вижу ветку, может Asmody ее удалил, после того как в КЗ опубликовал эту тему?

Но насколько знаю UML всетаки для объктно-ориентированной разрабтки, а если надо унифицированное описание бизнес-процессов?

в XP альтернативой служат клочки бумажки с обрывками мыслей или пожеланиями юзеров

А чем IDEF0  не моден? Вроде это классика.

Ок, понял, ее в ИнфТех перетащили, а у меня отбор стоял по 1с. + Так все-таки интересно можно ли для этого UML использовать.

Уж сколько лет прошло. IDEF0 был предложен в 1981 году. Конечно, это лучше, чем ничего, но тот же ARIS, например, гораздо удобнее.

"Сейчас модно использовать UML" Хм-м-м.. Это примерно как на вопрос об итальянском языке говорить, что С++ - форева :-))) UML и IDEF - это РАЗНЫЕ "ниши" :-)

говорят неподготовленные юзеры тяжело читают диаграммы, в ARIS якобы легче, т.к. там человечки, всякие фигурки

Конечно, можно использовать UML для описания (моделирования) бизнес-процессов. Для этого предназначен комплект диаграмм business use case model

Разумеется. UML гораздо шире и мощнее, чем IDEF. Ниша у IDEF0 очень узкая.

+ Вообщето IDEFов более десятка.. Вот "вершина айзберга": IDEF0 - методология функционального моделирования. С помощью наглядного графического языка IDEF0, изучаемая система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функций (функциональных блоков - в терминах IDEF0). Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы; IDEF1 – методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи; IDEF1X (IDEF1 Extended) – методология построения реляционных структур. IDEF1X относится к типу методологий “Сущность-взаимосвязь” (ER – Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе; IDEF2 – методология динамического моделирования развития систем. В связи с весьма серьезными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе. Однако в настоящее время присутствуют алгоритмы и их компьютерные реализации, позволяющие превращать набор статических диаграмм IDEF0 в динамические модели, построенные на базе “раскрашенных сетей Петри” (CPN – Color Petri Nets); IDEF3 – методология документирования процессов, происходящих в системе, которая используется, например, при исследовании технологических процессов на предприятиях. С помощью IDEF3 описываются сценарий и последовательность операций для каждого процесса. IDEF3 имеет прямую взаимосвязь с методологией IDEF0 – каждая функция (функциональный блок) может быть представлена в виде отдельного процесса средствами IDEF3; IDEF4 – методология построения объектно-ориентированных систем. Средства IDEF4 позволяют наглядно отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы; IDEF5 – методология онтологического исследования сложных систем. С помощью методологии IDEF5 онтология системы может быть описана при помощи определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент времени. На основе этих утверждений формируются выводы о дальнейшем развитии системы и производится её оптимизация.

"Разумеется. UML гораздо шире и мощнее, чем IDEF. Ниша у IDEF0 очень узкая" С точностью до наоборот :-)

кстати, говорят диаграммы в бизнес-процессах 1с 8  - это нечто близкое к IDEF3

Не согласен

"говорят неподготовленные юзеры тяжело читают диаграммы, в ARIS якобы легче, т.к. там человечки, всякие фигурки" не-е-е-а... ARIS как раз часто "сложнее"... Им тоже любят 2гвозди забивать" :-)

Диаграммы бизнес-процессов в 1С 8.0 "живые", если можно так выразиться. Их можно запускать, есть события, где можно размещать любой программный код.

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

да, многие так же считают что Арис сложнее по крайней мере в записи, т.к. это надо ещё знать значения всех этих десятков символов. А IDEF0 лаконичен я имел в виду - по нотации

Так реально, на практике кто-то пользовался UML в процессе проектирования и потом разработки конфигураций с нуля?

так вроде UML это для разработки на ООП языках

1С тоже в определённой мере объекто-ориентированная система

"1С тоже в определённой мере объекто-ориентированная система" Дипломатичное "в определённой мере" - очень ПОНРАВИЛОСЬ :-)))

Я уже доказывал это неоднократно. В поиск!

У нас аналитики пользуются... Но отчасти - в основном рисуют use case в Розе.

точно. Надо придумать диалект UML для 1С - с обозначениями для документов и проводок

Хорошо, спрошу по другому, кто чем пользовался на этапе проектирования конфигурации с нуля, притом достаточно большой, с производством, филиалами, МСФО и др. наворотами, вообще есть у кого такой опыт?

"Я уже доказывал это неоднократно. В поиск!" Хм-м.. а чЁ искать??? "определённую меру" ООП в 1С??? :-)

не мути воду, даже в vba есть ООП -  в "определённой мере" и в 1С эта мера даже больше :)

см - чистая правда.

Чем проект больше, тем лучше сразу приступать к разработке. Прототипа.

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

Берешь типовую и убираешь всё лишнее...

подписываюсь

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

Прототип лучше начинать с форм.

У меня база самописка небольшая на 12 доков 18 справочников, но огромный функционал и завязка на внешних системах (5 систем связано). Юзал UML.

>>месяца через 3-4 выяснялось что требуется такой функционал 3-4 это работы или писанины?

Форма определяет содержание, а потом содержание определеяет форму...

Писанины, с попутным пилотным внедрением.

Это надо что-то "в консерватории" менять...

В точку

я бы даже не так сказал: альтернатива IDEF0 - берёшь типовую и убираешь у предприятия всё лишнее

Кстати вспомнил - когда писал диплом не нашел ни одной методологии проектирования ПО заточенной под 1С, неужели до сих пор никто не разработал, мож кто слышал о такой?

Прикольно. Посмотри ТСКФ

Это бессмысленно. Точнее слишком затратно по сравнению с полученным эффектом.

Но при разработке типовых наверняка же что-то ипользуется, так вот что?

"берёшь типовую и убираешь у предприятия всё лишнее" - я тож так систему построил. Из типовой осталось 2 справочника и модуль КИ.. А если бы сразу бы в систему въехал дуростью не занимался бы.

Да хоть кусок мела с доской... Проблема в головах, а не инструментах... Опять ищете "серебрянную пулю".

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

На старой работе использовал "Use case" (сценарии или варианты использования). Просто пишешь текстом сценарий использования проектируемой системы - Например так --- 1. Пользователь вводит документ 2. Система формирует проводки 3. Пользователь радуется красивым отчетам ;-) Исключения 1. Системе не удалось сформировать проводки потому что пользователь лопух   и т.д. --- В чем преимущества 1. Всем понятно тебе, пользоваетелю (ему ведь неплохо бы объячснить что ты делать собрался). 2. Готовый план тестирования. 3. Готовый словарь предметной области. ... Подробности найдешь в книгах и инете.

"не мути воду, даже в vba есть ООП -  в "определённой мере" и в 1С эта мера даже больше :)" хм-м.. "осетрина бывает только одной свежести" (с) из классиков.. А "в определённой мере" - это лишь иллюзия и отмазка :-))) ЗЫ.. стати.. не путай VBA и VB... :-)))

эх, жаль ветку засирать :)

хм-м.. неужели так с умными мыслями напряг, что только нецензурщиной пользуешься??? :-) Действительно не в состоянии "грамотно сформулировать" аргументы???

Создайте новую

А смысл? Почему бы в ветке об IDEF-е и его альтернативе не поговорить об ООП  и том же 1С???

Ну например потому что idef0 придуман для описания бизнес процессов а вовсе не для моделирования ПО. Uml, как раз придуман  для моделирования ПО, хотя им, при наличии некоторой фантазии, и можно описывать БП. к чему это я... а вот, предлагаю понимать как предложение  не смешивать моделирование ПО и описание БП.

дЫк и я о чём? См :-) Только idef0 придуман не для "описания бизнес процессов", а как методология функционального моделирования... Между "описанием" и методологией функционального моделирования - тоже.. ГРОМАДНАЯ РАЗНИЦА :-)))

Есть такая штука: Business Process Modeling Notation. Поддерживается OMG, той самой которая UML, CORBA and so on. C этой BPML ознакомился поверхностно, трудно сказать чем она лучше/хуже IDEF0. Для меня выбор на уровне идеологии IDEF0 - старый закрытый стандарт родом из американской "оборонки"; UML - живой, современный и развивающийся. Нотация для бизнес процессов в лагере UML, получается, есть. IMHO, "умль" достаточно богатый и гибкий язык. Вполне можно попробовать приспособить его к проектам на 1С.

Н-да, блин, а тогда вопрос: нафига франчи на должности аналитиков требуют персонажей со знанием УМЛ??? Далее. По порядку по УМЛ: Основа УМЛ - "диаграмма классов" (первое, что создается из инфы вытащенной у специалиста предметной области при проектировании RAD3 (CORBA)). Вопрос: как классы представить в 1с? Ответ: наверное, справочниками! Вопрос: каким образом реализуется наследование в справочниках? Ответ: а это - возможно??? Справочники - ни фига не классы и о наследовании и речи быть не может! продолжать, думаю, бессмысленно. Стандарты нужны. Понятно же, что чем глубже в 1с, тем понятнее, что 1с - конфигуратор, а не язык ООП.

На форуме проскакивали анадысь диаграммы Константайна как наиболее подходящие для проектирования в 8-ке...

так я и не понял, зачем франчам УМЛ ?

Ты о чем, не слышал даже о таком, поясни плз.

Вы объясните, что вы получить хотите?

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

Вы занимаетесь фигней ИМХО... Ибо как я писал выше - результат будет "дешевле" затраченных усилий. Сужу не по теории - был у нас такой аналитик - сделал титанический труд - перевел все сущности конфы в диаграммы классов. Ну и кому стало легче? Оно конечно симпотично в тексте смотрится, но все сущности в 1С строго типизированы и какой смысл в диарамме класса для справочника? Состав реквизитов можно описать и в табличке, а описывать что у класса есть метод Записать - это накой? Тут более важна бизнесс-логика, а она может быть описана на use case и т.п. >>Не все же листками для заметок, салфетками и обрывками газет пользуются Кто мешает рисовать в Visio? В Rose? В Magic UML?

Спасибо - буду смотреть. Так в том то и дело, что мне не описание существующей конфигурации надо, а описание бизнес-логики, удобное для дальнейшей разработки конфигурации. Да, думаю остановлюсь на use case. Кстати вопрос по поводу Visio, работал и че-то эргономика не впечатлила, про другие слышал, но не работал, там как?

ужас какой. выглядит полным бредом

Че, серьезно? А я думал мож. пригодится, но всеравно посмотрю, а вдруг? Ну а какие есть реальные предложения?

Про use case уже писал чуть выше по ветке , но повторюсь, поскольку надеюсь, что это сохранит кого-то, если не тебя, от лишних проблем. Писать use case структурированным тектом существенно лучше, чем рисовать в диаграммах. Проверено на себе.