DRAKON.SU

Текущее время: Пятница, 29 Март, 2024 16:50

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 292 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7 ... 15  След.
Автор Сообщение
СообщениеДобавлено: Пятница, 08 Январь, 2010 21:06 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
Геннадий Тышов писал(а):
Извините, Вы столь умных много слов написали, прямо ужас.
Вот что действительно умнО, так это - внедрять забугорный стандарт двадцатипятилетней давности :wink:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 08 Январь, 2010 21:19 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Считаю вариант Геннадия удачным.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 09 Январь, 2010 00:18 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 42
Откуда: Бердск
Должен отметить, что это:
Вложение:
ParalDeistvia_.png
ParalDeistvia_.png [ 1.41 КБ | Просмотров: 17411 ]

- очень веселая конструкция, для банальной (читай - типовой) синнхронихации двух (хотя и с помощью пяти) потоков :wink:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 09 Январь, 2010 06:00 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Рэйлвэй Каген писал(а):
Драконограф писал(а):
Имеется в виду анализ наблюдаемых состояний предшествующих процессов, как в IDEF3?
- имеется в виду возможность декомпозиции икон "Адрес" и "Ветка".
Драконограф писал(а):
А как раскрывается такое взаимодействие в виде алгоритма?
- напоминает механизм, используемый для иконы "Вставка".

В таком случае большинство вопросов к данному предложению (назовём его РК-расширением техноязыка :)), полагаю, снимается. Весь анализ условий прохода, видимо, должен алгоритмизоваться как содержание декомпозируемого узла (включая запуск последующих при расщеплении); т.е. икона РК-Имя ветки, равно как и РК-Адрес, раскрывается следующей РК-схемой, и так пока РК-операторы не будут нужны по логике сочинителя?

Рэйлвэй Каген писал(а):
"невозможны цепочки одновидовых узлов (расщепление за расщеплением, сбор за сбором)" - нет, такие конструкции возможны и в примитиве, и в силуэте.

Как результат декомпозиции - да.

Рэйлвэй Каген писал(а):
"не просматривается принадлежность всех процессов дракон-модели к одной исходной модели поведения" - это нормальное состояние для различных уровней метасистемы.

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

Нет, я не о регламентации, просто на силуэте при множестве входов икон сбора (и выходов икон расщепления) просматривается больше линий, чем на тех же иконах примитива (по 4 вместо 2-х)...
Рэйлвэй Каген писал(а):
"как все возможные смыслы узлов воплощаются в алгоритмические конструкции" - руками и мозгами пользователя. Путём последовательной декомпозиции. Можно, конечно, присобачить построитель на базе паттернов, но это уже совсем другая песня :)

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 09 Январь, 2010 13:53 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
Драконограф писал(а):
расщепление за расщеплением, сбор за сбором..
Для силуэта будет выглядеть вот так(сделано в графическом редакторе:
Вложение:
joins.png
joins.png [ 4.03 КБ | Просмотров: 17386 ]
Вложение:
splits.png
splits.png [ 3.39 КБ | Просмотров: 17386 ]

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 09 Январь, 2010 15:10 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Рэйлвэй Каген писал(а):
Вот что действительно умнО, так это - внедрять забугорный стандарт двадцатипятилетней давности.

Не понял, ГОСТ 90-го года, который Геннадий использует как основу своего предложения, сам основан на чём-то "забугорном"?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 09 Январь, 2010 15:11 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Илья Ермаков писал(а):
Считаю вариант Геннадия удачным.

Более удачным, чем предложение Рэйлвей Каген? Видимо, есть какие-то основания?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 09 Январь, 2010 15:38 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
Драконограф писал(а):
Не понял, ГОСТ..
ISO 5807:1985
Revision information
Revises: ISO 1028:1973
Revises: ISO 2636:1973


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 09 Январь, 2010 19:48 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Геннадий Тышов писал(а):
А ведь можно проще, т.е. по ГОСТ 19.701-90. Смотрите ГОСТ 19.701-90
ИМХО, проще только с точки зрения встраивания в редактор. Схема неоправдано рвётся. Края параллельных линий вызывают ощущение обрыва, какой-то недоделанности.
Геннадий Тышов писал(а):
В и.с. DRAKON язык Дракон расширен понятием "Параллельные действия" из ГОСТ 19.701-90 и соответственно введена икона "Параллельное действие".
Какой смысл тянуться имено за этим изображением, если остальная Дракон-нотация очень слабо пересекается с указанным ГОСТом?

В предложении Рэйлвэй Кагена, кроме визуальной красоты и сохранения Дракон-нотации присутствует ещё потенция к развитию. ИМХО.

Я голосую за предложение Рэйлвэй Кагена.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 09 Январь, 2010 20:09 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Драконограф писал(а):
Ильченко Эдуард писал(а):
Кстати, «точка слияния» в паре с «точкой расщепления», на мой взгляд звучит лучше чем «точка сбора».

Согласен, только пусть будет "узел"; солидаризируюсь с Рэйлвей Каген, что это всё-таки не "безымянная точка", а нечто содержательно посложнее, и надо это отличать терминологически. Далее пользуюсь такой терминологией.
Вы согласились, что «узел слияния» звучит лучше чем «точка сбора». Тем не менее в тексте, практически везде употребляете выражение «узел сбора». Какой же вариант, по Вашему мнению, всё-таки предпочтительнее?

Драконограф писал(а):
Полагаю модель dvuugl частным случаем модели с узлами-перекрёстками, причём тип узла сбора неявно устанавливается...
...
Про диспетчеризацию было упомянуто не зря. Основная идея алгоритмизации модели с узлами расщепления/сбора процессов...
...
...из числа инициируемых асинхронным узлом сбора (т.е. допустимого раннего окончания некоторых процессов).
и т.д.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 09 Январь, 2010 20:22 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
Коллеги, мне кажется, что голосованием тут ничего не решить. Для каждого варианта, вероятно, существуют вполне объективные ограничения. Будучи однажды сформулированными, они и станут той "серебряной лопатой", которая закопает какой-то из вариантов.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 09 Январь, 2010 21:04 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
Ильченко Эдуард писал(а):
остальная Дракон-нотация очень слабо пересекается с указанным ГОСТом
А я, полагаю, что Дракон-нотация полностью на нем и основывается.
Ильченко Эдуард писал(а):
Схема не оправдано рвётся. Края параллельных линий вызывают ощущение обрыва, какой-то недоделанности.
Это и хорошо, подчеркивается, что все параллельные действия должны быть завершены для дальнейшего продолжения выполнения алгоритма.

Существование стандарта обязывает его выполнять. В UML использовано начертание сходное с ГОСТом. В и.с.DRAKON, по принципам языка Дракон, устранены наклонные линии и стрелки направлений. Дракон схемы, с параллельными действиями, приобретут всю функциональность UML диаграмм деятельности.

Отсюда
Цитата:
Диаграмма деятельности

Диаграмма деятельности, Activity diagram — диаграмма, на которой показано разложение некоторой деятельности на её составные части. Под деятельностью (англ. activity) понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов — вложенных видов деятельности и отдельных действий (англ. action), соединённых между собой потоками, которые идут от выходов одного узла ко входам другого.

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

Аналогом диаграмм деятельности являются схемы алгоритмов по ГОСТ 19.701-90.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 10 Январь, 2010 01:24 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Геннадий Тышов писал(а):
Ильченко Эдуард писал(а):
остальная Дракон-нотация очень слабо пересекается с указанным ГОСТом
А я, полагаю, что Дракон-нотация полностью на нем и основывается.
Вероятно, я чего-то недопонимаю.
Вложение:
гост1.png
гост1.png [ 21.87 КБ | Просмотров: 17315 ]
Вложение:
гост2.png
гост2.png [ 43.66 КБ | Просмотров: 17315 ]
Вложение:
гост3.png
гост3.png [ 36.49 КБ | Просмотров: 17315 ]
Вложение:
гост4.png
гост4.png [ 38.22 КБ | Просмотров: 17315 ]
Из 25! знаков в Драконе в чистую используются 5!. Процесс, предопределённый процесс, граница цикла, комментарий и терминатор. Остальные если и используются, то по другому, чем этого требует ГОСТ. Даже если учесть, что для схемы программы используются всего 12 знаков, то 5 из 12 считать основанием, ИМХО, натяжка. Разве что в понимании "положить кирпич в основание".

И ещё картинка из ГОСТа (для самостоятельного сравнения с Драконом : )
Вложение:
гост5.png
гост5.png [ 18.69 КБ | Просмотров: 17315 ]
Геннадий Тышов писал(а):
Существование стандарта обязывает его выполнять.
Неочевидно. Кого обязывает? Как выше уже показано, Дракон с ГОСТом имеет мало общего, тем не менее Буран запускали с помощью Дракона. Т.е. в самое советское время обошлись без обязательного ГОСТа : ) Чего уж говорить про современные коммерческие фирмы. (Я обратил внимание, что ГОСТ принят на 2 года позже полёта Бурана. Но это не отменяет сказанного : )


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 10 Январь, 2010 05:48 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Рэйлвэй Каген писал(а):
ISO 5807:1985

А, в этом смысле, а я думал, есть какой-то "забугорный" стандарт формализации знаний типа IDEF3, на котором основаны требования ГОСТа.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 10 Январь, 2010 05:53 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Рэйлвэй Каген писал(а):
Коллеги, мне кажется, что голосованием тут ничего не решить. Для каждого варианта, вероятно, существуют вполне объективные ограничения. Будучи однажды сформулированными, они и станут той "серебряной лопатой", которая закопает какой-то из вариантов.

Как я понимаю, на сегодня заявлены два предложения по расширению техноязыка; в чём-то они схожи, в чём-то разные. Можно говорить о "серебряной лопате", если сначала "докопаться" до ограничений каждого варианта, сначала хотя бы математических.
Ещё раз - как я понимаю ситуацию. Итак, у нас есть техноязык. Чтобы говорить на нём правильно, Паронджанов определил строгий шампур-метод построения/преобразования дракон-схем, а чтобы говорить красиво (эргономично) - также нестрогие преобразования дракон-схем (эквивалентные и равносильные). Чтобы другие могли говорить на техноязыке, создатель описал в своих работах как его стандарт, так и примеры. Исходя из этого и стало возможным построить технологию визуализации и автоматизированную систему её поддержки (алгоритмизовав некоторые элементы этой технологии, и прежде всего операции шампур-метода). Предложения Геннадия Тышова и Рэйлвей Каген задают некое расширение техноязыка; в основе его, как я понимаю, идея, так сказать, "мультишампур-метода": изображение на одной схеме разных процессов, которые в дальнейшем станут разными (но как-то связанными) алгоритмами. Чтобы говорить на языке этого расширения, нужен его итоговый стандарт, очевидно, также содержащий строгую и нестрогую части; суть его - как переходить от схемы поведения к совокупности алгоритмов, сохраняя связи, заданные схемой. Возможно, этот стандарт будет допускать разные подходы к визуализации (определены же в техноязыке для одной цели синхронизации два принципа - паузы и таймера). Очевидно, общедоступный стандарт выработать без участия авторов предложений будет сложно:); в то же время желательно чем-то "драконовским" заменить IDEF3-подобные методологии - чем меньше разных языков, тем "когнитивнее" и "эргономичнее". Но каждое предложение было определено фактически только на одном примере. Т.к. IDEF3 достаточно подробно описана и является родственной, то я использую её описание для сравнения с другими предложениями. Из сопоставления делаю те или иные предположения об их сущности (как можно убедиться, не всегда правильные :)). Однако нужна и более глубокая работа; хотелось бы, чтоб и она велась и привела к результату. Наверное, нужно широкое обсуждение людьми разной квалификации.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 10 Январь, 2010 05:57 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Ильченко Эдуард писал(а):
Вы согласились, что «узел слияния» звучит лучше чем «точка сбора». Тем не менее в тексте, практически везде употребляете выражение «узел сбора». Какой же вариант, по Вашему мнению, всё-таки предпочтительнее?

Т.к. я говорил только о паре "узел"-"точка", то в остальной части определения "перекрёстков" согласен с Вами, потому и употребляю "сбор".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 10 Январь, 2010 06:04 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Рэйлвэй Каген писал(а):
Ничего необычного, отвечу и на "детские".

Благодарю за терпение :)

Драконограф писал(а):
расщепление за расщеплением, сбор за сбором..
Рэйлвэй Каген писал(а):
Для силуэта будет выглядеть вот так(сделано в графическом редакторе:

Понятно: декомпозировать (я уж не буду отказываться от "умных слов" :)), т.е. строить каскады одновидовых узлов, можно прямо на той же схеме. А что эти узлы делают, определять в самих процессах?

Рэйлвэй Каген писал(а):
Выше осталась информация о том, за какую верёвочку дёрнуть, чтобы "построить дом". Это верхняя схема слева на рисунке "Дом".

В принципе я так себе и представлял, что есть некий "дёргатель", т.е. алгоритм "раскрутки" исполнения всей системы алгоритмов, так сказать, "начальный загрузчик". Но разве он не д.б. явным под именем исходной РК-схемы (в данном примере - построить дом), запуская её начальные процессы (здесь - Подготовка участка), от которых дальше уже пойдут команды следующим связанным процессам? Да, и вся схема, наверно, может начинаться и с узла?

Рэйлвэй Каген писал(а):
Повторюсь, в схеме силуэт эти линии не несут детальной информации(достаточно списка внутри икон), а в схеме примитив мы вынуждены рисовать эти линии соответственно числу соединений.

Вот балда (я о себе :)) - на другом сосредоточился и не подумал, что это ж просто "графическое троеточие"-указатель множественности...

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

Очевидно, есть какие-то общие соображения по правилам такой декомпозиции? Некий случай продемонстрирован на примере.


Рэйлвэй Каген писал(а):
д. даже отсутствие иконы "КОНЕЦ" никак не помешает дальнейшей алгоритмизации.

...видимо, поскольку достижение узла на РК-схеме и означает конец алгоритма (незацикленного) процесса, предшествующего этому узлу; переход же к узлу Вы визуализируете вставкой иконы "рандеву"? А если алгоритм зацикленный, как визуализируем переход к узлу? Ставим "рандеву" в любом месте?

Рэйлвэй Каген писал(а):
е. в отношении икон "Действие", "Вставка" и "Комментарий" ничего не изменяется. Они применяются в соответствии с базовыми правилами языка Дракон.

Т.е. можно вставить между узлами целый визуал (разумеется, с иконой Заголовок), чтобы, как хотел Эдуард Ильченко, открывая данную тему "все процессы показать в одном месте" (разумеется, если формат позволит)? А затем подставить вместо него икону Вставка?

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

Ну да, они нужны для разадресовки в петле. А в РК-схеме можно образовывать и циклы по принципу веточных?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 10 Январь, 2010 06:06 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
По поводу написанного Ильченко Эдуардом.

Геннадий Тышов писал(а):
А я, полагаю, что Дракон-нотация полностью на нем и основывается.
Это, не категоричное утверждение. Оно от В.Д. Паронджанова, в книге "Как ..." написано следующее:
Цитата:
... задачу решает язык ДРАКОН. Он построен путем формализации, неклассической структуризации и эргономизации блок-схем алгоритмов и программ, описанных в стандартах ГОСТ 19.701–90 и ISO 5807–85.

В ГОСТе удачный термин - "Параллельное действие", который определяет действие внутри дракон-схемы, в отличии от "Параллельный процесс" - действие в другой дракон-схеме. Эти два термина создают полный набор средств отображения взаимодействия действий.

Символ "Параллельный действия" имеет свое оригинальное начертание, основанное на отображении горизонтальной линии объединяющей несколько параллельных действий и одновременно изолирующих их от части дракон-схемы с последовательным выполнением. Он функционально выполняет туже роль, что и широкая черта в символах UML "раздел" и "слияние".

В любой работе хорошим тоном является использование существующих стандартов.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 10 Январь, 2010 14:20 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
2Драконограф
"Понятно: декомпозировать (я уж не буду отказываться от "умных слов" ), т.е. строить каскады одновидовых узлов, можно прямо на той же схеме. А что эти узлы делают, определять в самих процессах?"
    -Да, вариант позволяет сочетать декомпозицию на плоскости(разделение на ветки) и иерархическую(подобно "Вставке").
По поводу "дёргателя":
    -Вместо него предпочтительней было бы воспользоваться средствами гипотетической(пока) среды разработки для формирования "сводного отчёта" каждую конкретную цель(моделирование, компиляция, использование ресурсов и т.д.). Но это уже прикладной уровень. Хотелось бы пока определиться с системным :)
"Очевидно, есть какие-то общие соображения по правилам такой декомпозиции?"
    -На системном уровне языка Дракон - это декомпозиция на плоскости(разделение на ветки и маршруты) и иерархическая(представление одной иконы в виде силуэта или примитива)
"переход же к узлу Вы визуализируете вставкой иконы "рандеву"?"
    -Нет. Это один из способов организации взаимодействия процессов, использованный для реализации конкретной системы.
"Т.е. можно вставить между узлами целый визуал (разумеется, с иконой Заголовок).. затем подставить вместо него икону Вставка?"
    -Не понял вопрос. Между иконами "Адрес" и "Ветка":
    1. по петле силуэта возможно только присоединить "Заголовок" для обозначения дополнительного входа.
    2. в пределах ветки силуэта "Заголовок" посреди маршрута никак не вставите. Вот "Вставку" - пожалуйста. И далее раскрывайте её примитивом или силуэтом.
"можно образовывать и циклы по принципу веточных?"
    -Конечно можно. И в модифицированном варианте тоже.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 10 Январь, 2010 15:19 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Геннадий Тышов писал(а):
В любой работе хорошим тоном является использование существующих стандартов.
Вот бы ещё редактор под существующие стандарты : ) Шутка. Visio не предлагать : )


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 292 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7 ... 15  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 4


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2008-2024, участники конференции «DRAKON.SU», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB