При написании конфигурации на определенном этапе, который уже у меня наступил, начинаю путаться в собственной конфигурации. А все потому, как я думаю, что порядка нету. Что-то сегодня придумал, реализовал, через месяц забыл, потом опять придумал опять начинаю реализовывать - выясняю что уже это есть и т.д. и.т.п. короче дурдом.
Прихожу в очередной раз к мысли что голова всего не упомнит и надо все по полочкам разложить или как вариант красиво нарисовать. Пусть это время займет, потом переделывать меньше.
Как я понял надо бить по UML. Погуглил немножко одну статейку нашел http://www.ильяфедоров.рф/.
На мисте тоже этот вопрос раньше обсуждался, а сейчас тишина. На старой ветке Проектирование: Опыт применения элементов RUP в проектах 1С:Предприятие вроде то что надо, но ссылка на скачивание не работает, гугл ничего не дал, точнее дал но тоже ссылки не работают. Может у кого есть метода указанная там? Ну или может другая инфа по данному вопросу?

Уточнение.
Народ тока я вас умоляю не надо обсуждать мои умственные и другие способности. Только конкретику пожалуйста. Спасибо.

(1) Типа в точку... Спасибо.

(0) для "не запутаться бы" можно и без UML обойтись, почитай по майндмаппинг, скачай Freemind или еще лучше Xmind, и просто структуированно опиши там, что ты вообще такое делаешь

http://v8.1c.ru/model/

(0) >> начинаю путаться в собственной конфигурации.
Никогда не понимал-как можно запутаться в собственной конфе?

v8: Опубликована Система проектирования прикладных решений Версия 1.1.3.3
1С использует при пректировании типовых

(6) 1С ни разу не авторитет в проектировании типовых решений. Архитектурные решения в типовых можно искать с таким же успехом, как и  талию у толстушки 160х160х160. Какой инструмент они могут предложить?

Первое. С развитием сред программирования CASE средства становятся не нужны. Основной конь UML - генерация кода, щитай сдох.

Второе. Схемы UML никто не понимает кроме одного-двух ITшников в компании, которые тоже понимают его на 50%.

Третье. Сам по себе RUP настолько гибкий, что уже никто и не может сказать что это такое, за исключением названий терминов которыми он оперирует. Т.е. жесткие регламенты по ведению проекта пользователь RUP должен определить сам. А это не каждый сможет сделать.

Но некоторые понятия UML мне все-таки нравятся, пусть и хорошего перевода нет:

http://s1.ipicture.ru/uploads/20130723/1YU9Ee8j.png

Автор не хочет путаться в собственной конфигурации. Автор хочет путаться в UML.

Ждем про ООП.

(9) прав

если порядка нет изначально, то схемы его не добавят

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

+(9)
uml используется  для описания процессов разработки, взаимодействия разработчиков это для RUP

и взоимодействия обектов моделирования - собственно то что нужно автору.

так что rup не причем.

(0)
суть:
разбить конфу на логические части. а умл это всего-лишь инструмент. ты от него не получишь ничего.

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

бумага и карандаш
остальное - всё ненужное забивание мозга..
ИМХО..

(15)напиши на бумажке схему виндовса.

(16) элементарно, ватсон.. в центре круг, от него лучи во все стороны, на их концах - приложения.

(17) зачет! иди обмывай.

(0) UML не подходит для проектирования в 1С чуть более чем полностью

(18) не устраивает? :) тогда круг можно разделить на сектроа, сегменты, и пр. виды делимостей, в соответствии с количеством библиотек и утилит :)

если уж нет надежды на память - надо не лениться оставлять в каждой доработке свои метки.. типа столбики у дороги.. :)
типа
//здесь был [такой-то], оставил нетленку в назидание гразущи поколениям 1с-ников :)

+21 а далее - просто глобпоиск по тексту [такой-то]

гразущи = грядущим

пока 1С придумывает "свое ооп" этот цирк будет продолжаться

(0) Вектор правильный, но UML может помочь а может усугубить существующие проблемы.  Используй его без фанатизма, только в той части, которая поможет структурировать проблему, описать систему, решение или алгоритм.
Попытайся выработать четкие принципы применения UML. Для этого научись мыслить в терминологии UML. Тогда вопрос о степени документирования отпадет сам собой.
Особенно важно провести аналогию между базовыми понятиями UML и 1С. В приведенной тобой ссылке Федоров, имхо, неверно определил аналог Use Case. В такой аналогии нормальные (полезные) диаграммы UC не построишь. Я использую такую : UC (UML)- форма (1С).В таком варианте  Все отлично вписывается и описывается )))

Почаще применяй принцип сверху-вниз (от общего к частному). Декомпозируй. В (17) отличная демонстрация этого принципа.

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

(19) Вы просто не умеете его готовить)) При помощи UML отлично можно описать 1C (как, впрочем, и любое ПО). Это же язык)))

придумал принцип "АКС" ))
- Анализируй (предметную область, архитектуру, код...)
- Классифицируй (разделяй различное, объединяй похожее)
- Систематизируй (выявляй связи, выстраивай систему)

Не торопитесь, я записываю.

надо изучать не UML а ARES-диаграммы

(27) Копипаст тебе в помощь )))
(28)возможно ARIS? Хотя.. какая разница, слово то красивое ))

(29) точно, арис ) книжка валяется "BPM для начинающих. Моделирование бизнеса в ARIS Design Platfom", руки не доходят прочитать. В аналитеги потом можно идти )

поставь обычный багтрекер-планировщик(redmine, drupal+storm, opencart, jira, ...)
и потом по истории тикетов/задач все можно норм найти.

(31) жира платная вродеб

Нужно просто понятно описание конфигурации.
К каждому объекту или важной процедуре делать описание: когда и почему так сделано. И ссылки на связанные объекты.
И не нужно никаких схем.

В идеале, должно быть что-то типа wiki по конфигурации.

(32) ну значит ее вычеркиваем, и так тормозила через жаву реализацию :)

>Второе. Схемы UML никто не понимает кроме одного-двух ITшников в компании, которые тоже понимают его на 50%.

вокруг все настолько непроходимо тупы что не в состоянии вкурить 3-4 вида диаграмм?

(33) Я как то думал поставить DokuWiki и вести заметки но почти сразу забил

(35) Таки представляю как методист или бух трепетно постигает наследование юзкейсов за книгой Фаулера.
А если эти схемы варятся чистов в среде кодеров, в стороне от т.н. экспертов предметной области, накой они нужны?

>А если эти схемы варятся чистов в среде кодеров, в стороне от т.н. экспертов предметной области, накой они нужны?

кодерам они зачем? у нас кейсы аналитики рисовали

но прочитать их - много ума не надо... тем более что в 1С кроме ER, usecase, активности и последовательности больше нафиг не надо ничего...

(37) "А если эти схемы варятся чистов в среде кодеров, в стороне от т.н. экспертов предметной области, накой они нужны?" =>  
1. Диаграммы UML кодерам не нужны. Этот вывод из твоей реплики - фигня полная, в этом направлении говорить больше неочем.
2. В UML целый слой понятий для описания бизнес моделей.
То, что ты суешь юзерам не те диаграммы, говорит  об уровне твоей профпригодности.
3. Ты слишком поверхностно понимаешь UML. Отсюда такие категорические высказывания и непонимание сферы применения UML.

(39) диаграммы состояний еще могут быть полезными

(40)
Кодерам не нужны... Диаграммы классов особенно.

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

Про юзкейсы: " Я использую такую : UC (UML)- форма (1С)"

Да уж верх понимания. Даже если не принимать во внимание смешивание в одну кучу UC и варианта его реализации в 1С (форма), то системные UC ты какими формами описывать собрался?

(41) и мне ясен )). Ну продолжи свою мысль))
UML язык ->  язык это средство общения -> основное назначение -> обеспечить коммуникацию, передачу информации, обсуждение -> использовать его надо для этих целей, а не ради использования как такового.
Другими словами, если "накидать нечеткую модельку на клочке туалетной бумаги используя значки UML" поможет решить проблему лучше чем при описании с помощью другой нотации, значит я буду использовать  UML))) И не надо  заморачиваться на неполном использовании "...четкого и обширного..." Русский тоже велик и могуч. Много мы используем от его могущества в каждой конкретной ситуации? ;-)

Ты же склоняешься к  максимализму. Если UML, то от корки до корки, если модель - то от микро до макро. Иначе нафиг ))

(0) UML сам по себе особого толка не добавит, так как, чтобы был толк, потребуется изобрести и обкатать методологию: какие аретфакты языка и как применять. В общем, это велосипедостроение не понятно, сколько будет длиться и закончится ли оно вообще. В этом плане разумнее использовать готовый вариант - СППР (4) - методология доступно изложена в мануале, нотация IDEF0 (усеченная) доступна даже бизнес пользователям практически без подготовки. Однако не надо считать, что это просто - прочитал мануал и готово. Моделированию нужно учиться и быть готовым к тому, что по началу будет вот такая жопа:
http://savepic.org/4168764.jpg
http://savepic.org/4158524.png

ЗЫ Это, кстати, дела давно минувших дней - реальные примеры мыслеизлияний в СППР начинающих оналитегов.

первая чо-то не работает http://savepic.org/4168767.png

(42) ну это уже конструктивнее. Форма и есть реализация UC. Системные ВИ это такие же ВИ, только акторы там другие и уровень цели другой. US, вариант использования, сценарий использования - а уж кто кого юзает - вопрос цели моделирования.

И в этом, имхо, основная проблема в использовани UML. Народ не знает где провести черту между Уровнем цели пользователя и уровнем цели системы. Где остановиться в описании модели: описании мельчайших подробностей или  на нотации взаимодействия основнрых подсистем

еще к(42): аналогия  UC - форма я использую для описания ВИ уровня цели пользователя. В нашем деле (автоматизация 1С)jписание UC уровня системы считаю нецелесообразным (по многим причинам) и не описываю ))
Друже, меру нада знать и все будет ОК ))

(44) конкретнее про усеченность IDEF0 в СППР можно? Неохота ковыряться. Пара попыток наткнулись на ошибку в конфигурации, я и забросил ))
Усеченность IDEF настораживает. IDEF (SADT)  продуман и выверен. Если в нем наусекать, то следствием и будут такие диаграммы как на ссылках из твоего поста.

(48) механизмов нет за тотальной ненадобностью.
А из коробки он глючен, да. Причем так - угрюмо глючен... По крайней мере прошлый, до крайнего июльского еще рукти не дошли потрогать

(49) У меня июльский (демо на сайте) на 2 клике мышью сломался, потом на 5ом и я бросил это дело)))
а IDEF без мех-мов... хотя у них там все с ног на голову.  Декларируется так:
"На основании логической модели строится физическая модель, воплощаемая в метаданных разрабатываемой конфигурации."
а на поверку так: http://v8.1c.ru/model/images/list_of_metadata.png

Спасибо за реакцию на мой вопрос. Прочитал с интересом.
И как я понял малая/мизерная доля использует UML.
На самом деле мне UML нужно именно для того, чтобы "накидать нечеткую модельку на клочке туалетной бумаги используя значки UML". Ничего больше от UML мне не надо. Идеальный вариант это накидать схемы - распечатать на бумаге  - повесить над столом, чтобы видеть общую структуру.
Карты ума - возможно их тоже можно использовать, я как-то даже очень заинтересовался этой темой, но вот как применить не сообразил.
Карандаш и бумага - тоже хорошо, но нужно учитывать, что схемы приходиться несколько раз перерисовывать, изменять никакая бумага от ластика на выдержит, ну разве что ватман :).
Как раз таки именно UML (в моих мыслях) и даст мне в руки тот карандаш и бумагу. Плюс рекомендации в (25).
Уважаемый Chernik можно как-то поподробней как ты используешь, ну или пытаешься использовать UML. Хорошо бы пару схем для примера увидеть. Напиши мне на ящик, он есть в личной карточке.