OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Среда, 26 Сентябрь, 2018 12:16

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




Начать новую тему Ответить на тему  [ Сообщений: 52 ]  На страницу 1, 2, 3  След.
Автор Сообщение
 Заголовок сообщения: Цикл для атомных станций
СообщениеДобавлено: Пятница, 01 Декабрь, 2017 18:33 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 693
Откуда: Киев
Исходя из рекомендаций к коду для атомных станций, которые регламентируют, что цикл должен иметь константное максимальное количество итераций и того, что в общем случае проанализировать количество итераций для инструментальных средств может быть затруднительным, то, по-хорошему, язык должен предоставлять цикл подобного вида:
Код:
Loop =
  IdentOk ":=" LOOP Limit WHILE Expression DO
    Statements
  END .

Limit = ConstExpr | MIN(ExprLimit, ConstExpr) .

Или какого другого? Или не должен?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Цикл для атомных станций
СообщениеДобавлено: Пятница, 01 Декабрь, 2017 20:48 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 274
Откуда: Москва
Для категории A установлены требования по стандарту 60880:
Цитата:
B.4ag Следует использовать циклы только с постоянными максимальными областями значений переменной цикла

Как реализовывать, в стандарте не сказано.

Ваш пример - это, видимо, вариант линейного поиска, но с зафиксированным максимальным значением и результатом поиска. Для сертификационной комиссии такая реализация будет являться доказательством, в отличие от универсального цикла WHILE, где не гарантирован предел числа итераций. Единственное возражение - предел должен быть постоянным, а не ExprLimit.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Цикл для атомных станций
СообщениеДобавлено: Пятница, 01 Декабрь, 2017 21:13 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 693
Откуда: Киев
Дмитрий Дагаев писал(а):
Единственное возражение - предел должен быть постоянным, а не ExprLimit.
Насколько я понял это утверждение
Цитата:
B.4ag Следует использовать циклы только с постоянными максимальными областями значений переменной цикла
Выражение
Код:
MIN(ExprLimit, ConstExpr)
вполне соответствует ему, так как позволяет ограничить сильней, чем максимальное постоянное значение.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Цикл для атомных станций
СообщениеДобавлено: Пятница, 01 Декабрь, 2017 21:20 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 274
Откуда: Москва
А, минимум, не посмотрел, тогда все соответствует.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Цикл для атомных станций
СообщениеДобавлено: Понедельник, 26 Март, 2018 20:10 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 226
Прочитал возникшую недавно здесь на форуме дискуссию по поводу отладчиков -- их нужности/бесполезности и прочая смежная проблематика, прежде всего понимание "отладки" и "доказательства". В результате вспомнилась эта ветка форума -- вообще-то с непростым вопросом в начале. Лично я в своей практике напрямую не связан с жёсткой системой сертификации/валидации, поэтому мои впечатления лишь косвенные и неоднозначные, о чём ниже.
Дмитрий Дагаев писал(а):
Для категории A установлены требования по стандарту 60880:
Цитата:
B.4ag Следует использовать циклы только с постоянными максимальными областями значений переменной цикла

Как реализовывать, в стандарте не сказано.

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

Вот в том и дело, что весь смежный раздел форума про программирование "под доказательство" кричит о том, что сертификационная комиссия -- "контуперные гении", как и создатели этого стандарта, мол не умеют пользоваться инвариантами циклов, ограничивающей функцией и т.д.
Яркий пример попыток добиться соответствия подобным стандартам -- последний Safety-Critical Java, где учитывают уже накопленный опыт промышленных профилей. Там циклы задаются в форме с обязательной границей:
Код:
// вместо аналогов:
for(Entry e = tab[i]; e != null; e = e.next)

// необходимо примерно так:
Entry e = tab[i];
for (int j = 0; j < entries.length; j++) {
    if (e == null) break;
    ...
    e = e.next;
}

А также требуется явно уточнять семантику границ, если она определяется косвенно, аля:
Код:
@LoopBound(max=elementCount)
for (int i = 0; i < elementCount; i++){...}

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

В принципе, понять "контуперных гениев" из стандартизации можно. Ниже пример техники автоматического поиска инварианта цикла и контроля завершимости:
Better termination proving through cooperation

Примерчик из статейки выше:
Код:
y := 1;
while x > 0 do
    x := x − y;
    y := y + 1;
done

, где акцент на том, что изменение x (его уменьшение) зависит от изменения y -- понимание зависимостей есть основная забота при верификации (о чём и статья, кроме прочих не менее сложных проблем, как использование указателей и др.) и такая задача отнюдь не проста (в т.ч. и проверка корректности задаваемых деклараций контракта).
И, фактически, в той же Safety-Critical Java проблематика циклов, связанных с условно бесконечными данными, вводом-выводом и т.п. трансформируется в целом в проблему управленческих циклов -- построение и анализ моделей взаимодействующих процессов, с совсем другой природой проверок. В случае вычислительных алгоритмов поверх конечных структур данных поступают максимально "прямее", "в лоб" (к слову, аналогичная картина вырисовывается и в смежной ветке форума про Esterel/Lustre, однако вместо циклов "for" в языках применяются контролируемые функции-итераторы вида map/reduce и т.п.).

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Цикл для атомных станций
СообщениеДобавлено: Понедельник, 26 Март, 2018 21:38 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 693
Откуда: Киев
PSV100 писал(а):
Вот в том и дело, что весь смежный раздел форума про программирование "под доказательство" кричит о том, что сертификационная комиссия -- "контуперные гении", как и создатели этого стандарта, мол не умеют пользоваться инвариантами циклов, ограничивающей функцией и т.д.
Кто на кого кричит?
Сертификация должна быть осуществима, желательно простыми средствами. С учётом ограниченного круга применения, требование не выглядит слишком странно.

Цитата:
И впечатление, что какой-нибудь Питон (особенно с учётом потенциальной аннотации типов и соответствующего контроля) лучше адаптирован к стандарту, чем те же Обероны

Интересное впечатление :lol: .
Статическая типизация в Python3 - это отдельная песня:
Код:
"""Static typing in Python"""

def static_typing(i: int) -> int:
    """With type's annotations much more safe"""
    return "bla bla" + i

print(static_typing(" bla"))

В простых случаях может помочь mypy, но это слабое утешение:

Код:
"""Static typing in Python"""

def ret():
    """mypy save you in all cases"""
    return "bla bla "

def static_typing(i: int) -> int:
    """With type's annotations much more safe"""
    return ret() + i

print(static_typing(ret()))


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Цикл для атомных станций
СообщениеДобавлено: Вторник, 27 Март, 2018 17:39 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 226
Comdiv писал(а):
PSV100 писал(а):
Вот в том и дело, что весь смежный раздел форума про программирование "под доказательство" кричит о том, что сертификационная комиссия -- "контуперные гении", как и создатели этого стандарта, мол не умеют пользоваться инвариантами циклов, ограничивающей функцией и т.д.

Кто на кого кричит?

"Крики" были (и очень полезные) в соответствующем разделе форума лет так 6-8 назад, когда тамошние темы были актуальны, да и участники баталий были помоложе, поэнергичнее, "мочили" т.н. контуперных гениев ("должность" популярная в тех ветках форума), игнорирующих методику "под доказательство".
Comdiv писал(а):
Сертификация должна быть осуществима, желательно простыми средствами. С учётом ограниченного круга применения, требование не выглядит слишком странно.

И вот, если дело доходит до реальных стандартов безопасности, то выясняется, что дисциплина "доказательства для человеков" не является достаточно убедительной и надёжной. Конечно же, реальные процессы сертификации/стандартизации не только технические, но и политические, где возможны всяк разные варианты соглашений о "доверии". Однако, всё же в целом необходимы какие-то средства доказательства, те же контракты в каком-то виде, к примеру, с гарантией корректности, полноты деклараций и т.д. (поэтому, напр., в упомянутой здесь выше Esterel/Lustre недопустимы широкие произвольные рассуждения по Хоару/Дейкстре/Грису и т.п., как минимум в рамках базовых средств валидации). Если соответствующих инструментов нет, то в рамках Паскале/С-подобных языков имеется лишь одно допустимое стандартами средство -- цикл for, без него не о чем говорить (видимо, в т.ч. и насчёт "принципов Калашникова" тоже). Иными словами, "бяка" по методике "под доказательство" -- for + break/exit -- является единственной допустимой формой в реальных стандартах безопасности.
Comdiv писал(а):
PSV100 писал(а):
И впечатление, что какой-нибудь Питон (особенно с учётом потенциальной аннотации типов и соответствующего контроля) лучше адаптирован к стандарту, чем те же Обероны

Интересное впечатление :lol: .

Ситуация действительно смешная. Если на борту нет средств доказательств, и в простом "надёжном" императивном языке нет цикла for или break/exit для него -- язык теоретически не применим для стандартов безопасности (в отличие от того же Питона с его паттернами for+break+else, будь у него полноценная статическая типизация. А может быть для некоторых "сертификационных комиссий" и такая сойдёт -- она же есть, мол стандарту соответствует).

Повторюсь, что в реальной практике, видимо, какие-то компромиссы возможны (а то и неизбежны). Может быть для задач и достаточно for-а без exit-а, или возможно введение каких-то библиотечных средств для циклов (аля map/reduce/fill и пр.) с подтверждением "доверия" и т.п. Я не акцентирую на буквоедстве насчёт самого Оберона. Возникают неоднозначности в "классической" методике "под доказательство", если не игнорировать реальные промышленные стандарты безопасности. Или в стандартах безопасности, уж не знаю.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Цикл для атомных станций
СообщениеДобавлено: Вторник, 27 Март, 2018 18:00 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 693
Откуда: Киев
PSV100 писал(а):
Если соответствующих инструментов нет, то в рамках Паскале/С-подобных языков имеется лишь одно допустимое стандартами средство -- цикл for, без него не о чем говорить (видимо, в т.ч. и насчёт "принципов Калашникова" тоже). Иными словами, "бяка" по методике "под доказательство" -- for + break/exit -- является единственной допустимой формой в реальных стандартах безопасности.
Сумбурно как-то.
1. В рамках многих С-подобных языков нет for такого же, как в Паскале. Есть лишь синтаксическое подобие, само по себе ничего не гарантируещее.
2. Как можно прочесть в цитате и пояснинии Дмитрия Дагаева, в стандарте не указано, как именно реализовывать постоянные границы переменной цикла. Поэтому такой вариант, особенно с учётом п.1 тоже подходит
Код:
i := 300;
WHILE (0 < i) & SomeCondition() DO
    DEC(i);
    SomeDo()
END
Поэтому все остальные рассуждения про надёжность и теоретическую(!) неприменимость неверны.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Цикл для атомных станций
СообщениеДобавлено: Вторник, 27 Март, 2018 19:34 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 226
Comdiv писал(а):
1. В рамках многих С-подобных языков нет for такого же, как в Паскале. Есть лишь синтаксическое подобие, само по себе ничего не гарантируещее.
2. Как можно прочесть в цитате и пояснинии Дмитрия Дагаева, в стандарте не указано, как именно реализовывать постоянные границы переменной цикла. Поэтому такой вариант, особенно с учётом п.1 тоже подходит
[...]
Поэтому все остальные рассуждения про надёжность и теоретическую(!) неприменимость неверны.

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Цикл для атомных станций
СообщениеДобавлено: Вторник, 27 Март, 2018 21:11 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 274
Откуда: Москва
Все-таки главное в 60880 - обеспечить(верифицировать) отсутствие зависаний в циклах путем ограничения числа итераций. Причем, как для системного кода, так и для сгенеренного в будущем прикладного ПО. Поэтому, лучше всего писать специальный компилятор с одним и только одним циклом, как в начале темы. Поэтому допилить для данной задачи именно Оберон-07 представляется разумным, а ПИТОН с брейком гарантий не предоставляет. Фреймворки, конечно же пытаются представить сгенеренный ими код как безошибочный, но это очень сложно доказать.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Цикл для атомных станций
СообщениеДобавлено: Вторник, 27 Март, 2018 21:27 

Зарегистрирован: Вторник, 27 Февраль, 2018 09:18
Сообщения: 53
Дмитрий Дагаев писал(а):
Фреймворки, конечно же пытаются представить сгенеренный ими код как безошибочный, но это очень сложно доказать.

А как доказывается, что в самом компиляторе нет ошибок?
Ну, смотрит проверяющая комиссия на цикл LOOP Limit WHILE Expression DO и думает, что этот цикл ограничен. А на самом же деле в компиляторе ошибка, и он вообще забыл добавить проверку на "Limit".


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Цикл для атомных станций
СообщениеДобавлено: Среда, 28 Март, 2018 14:01 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8989
Откуда: Россия, Орёл
Дмитрий Дагаев писал(а):
Все-таки главное в 60880 - обеспечить(верифицировать) отсутствие зависаний в циклах путем ограничения числа итераций.


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Цикл для атомных станций
СообщениеДобавлено: Среда, 28 Март, 2018 15:25 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 693
Откуда: Киев
Владимир Ситников писал(а):
А как доказывается, что в самом компиляторе нет ошибок?
В стандарте предусмотрена возможность ошибок в компиляторе. А Вы как думали?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Цикл для атомных станций
СообщениеДобавлено: Среда, 28 Март, 2018 15:39 

Зарегистрирован: Вторник, 27 Февраль, 2018 09:18
Сообщения: 53
Comdiv писал(а):
Владимир Ситников писал(а):
А как доказывается, что в самом компиляторе нет ошибок?
В стандарте предусмотрена возможность ошибок в компиляторе. А Вы как думали?

Я думаю, что смешно звучит, когда упоминают Python и сетуют на то, что там "нет ограничителя циклов".

Проще уж на уровне компилятора сделать принудительное ограничение количества итераций каждого цикла. И всё. Никакие LOOP Limit не нужны.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Цикл для атомных станций
СообщениеДобавлено: Среда, 28 Март, 2018 16:26 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 693
Откуда: Киев
Владимир Ситников писал(а):
Я думаю, что смешно звучит, когда упоминают Python и сетуют на то, что там "нет ограничителя циклов".
Где Вы увидели именно то, что назвали?

Цитата:
Проще уж на уровне компилятора сделать принудительное ограничение количества итераций каждого цикла. И всё. Никакие LOOP Limit не нужны.
Не знаю проще ли это, но неявное ограничение - это плохое решение.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Цикл для атомных станций
СообщениеДобавлено: Среда, 28 Март, 2018 16:48 

Зарегистрирован: Вторник, 27 Февраль, 2018 09:18
Сообщения: 53
Comdiv писал(а):
Где Вы увидели именно то, что назвали?

Вот же:
Дмитрий Дагаев писал(а):
допилить для данной задачи именно Оберон-07 представляется разумным, а ПИТОН с брейком гарантий не предоставляет


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Цикл для атомных станций
СообщениеДобавлено: Среда, 28 Март, 2018 16:59 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 696
Откуда: Казань
Илья Ермаков писал(а):
Дмитрий, но тогда должно быть и обязательное требование после цикла явно обрабатывать завершение его по "исчерпанию предела итераций", как ошибочное.
Иначе можно получить такой логический сбой.... проигнорировав эту ситуацию.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Цикл для атомных станций
СообщениеДобавлено: Среда, 28 Март, 2018 16:59 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 693
Откуда: Киев
Владимир, Вы не видите разницу между
Дмитрий Дагаев писал(а):
ПИТОН с брейком гарантий не предоставляет
и
Владимир Ситников писал(а):
упоминают Python и сетуют на то, что там "нет ограничителя циклов".
?
Это сильно разные утверждения и подмена понятий. Поэтому я и спросил - "где Вы увидели именно то, что назвали?".


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Цикл для атомных станций
СообщениеДобавлено: Среда, 28 Март, 2018 17:10 

Зарегистрирован: Вторник, 27 Февраль, 2018 09:18
Сообщения: 53
Comdiv писал(а):
Серьёзно? Это сильно разные утверждения и подмена понятий.


Серьёзно.

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


Дмитрий вполне конкретно сказал, что, якобы, требуется ограничивать количества итераций.
И он считает, что некий язык ПИТОН не предоставляет "гарантий". Каких? Разумеется про "ограничение на количество итераций", т.к. это вообще единственное, что упоминалось в этом сообщении.

Поэтому я и говорю, что забавно, когда говорится, что "ПИТОН гарантий не предоставляет, а Оберон-07 допилить представляется разумным".
Откуда возьмётся гарантия в Оберон-07 отдельный вопрос, и сейчас это утверждение голословное.

Я к тому, что гарантии возникают не из-за наличия-отсутствия синтаксиса языка. Компилятор (интерпретатор тоже важен)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Цикл для атомных станций
СообщениеДобавлено: Среда, 28 Март, 2018 17:59 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 693
Откуда: Киев
Владимир Ситников писал(а):
Дмитрий вполне конкретно сказал, что, якобы, требуется ограничивать количества итераций.
И он считает, что некий язык ПИТОН не предоставляет "гарантий". Каких? Разумеется про "ограничение на количество итераций"

Это утвеждение верно - язык Python не предоставляет гарантий. И повторюсь, это не то же самое, что сетовать, что в языке нет ограничителей цикла.

Цитата:
Откуда возьмётся гарантия в Оберон-07 отдельный вопрос, и сейчас это утверждение голословное.
Там было вполне понятное объяснение, как этого достичь.

Цитата:
Я к тому, что гарантии возникают не из-за наличия-отсутствия синтаксиса языка
Складывается впечатление, что Вы отделяете проектирование синтаксиса от проектирования семантики и воплощения компилятора, но это неверно. Желая получить определённые гарантии, мы можем задать определённую семантику, для выражения которой создаётся синтаксис. Для работы со всем этим создаётся исполнитель(интрепретатор), который может включать компилятор. Всё это звенья одной цепи.

Вы пишете, что компилятор тоже важен. Кто-то утверждает обратное?


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

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


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

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


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

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