OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Пятница, 15 Декабрь, 2017 20:49

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




Начать новую тему Ответить на тему  [ Сообщений: 15 ] 
Автор Сообщение
СообщениеДобавлено: Вторник, 18 Февраль, 2014 11:00 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8904
Откуда: Россия, Орёл
Степан Митькин, автор DRAKON Editor (http://drakon-editor.sourceforge.net/, viewtopic.php?f=79&t=3716), сделал и поддержал в своей программе компактный визуальный язычок моделирования данных и объектной структуры - ERIL.
http://drakon-editor.sourceforge.net/eril.html

На мой взгляд, то, чего давно хотелось: самый необходимый "отжим" из "UML-ей всяких", по сути - улучшенные ER-диаграммы. Плюс строгие визуальные правила их черчения, как в ДРАКОНе.

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

Для студентов вчера сделал перевод документации ERIL на русский язык:
Вложение:
ERIL_ru.7z [432.09 КБ]
Скачиваний: 197


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 18 Февраль, 2014 11:07 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8904
Откуда: Россия, Орёл
Из моей лекции студентам. Мы не собираемся подробно забурятся в вопросы UML и прочего, нам нужна просто возможность какие-то архитектурные вещи визуализовать, в процессе разработки учебных проектов. И для этого был выбран ERIL.

Из лекции Ермакова писал(а):
Графическое моделирование программных систем

Что такое модель? Это какое-то отражение существенных черт оригинала. Оригиналы в данном случае - это решаемая программой задача и устройство самой программы.
Графическое моделирование может использоваться и на этапе анализа задачи, и на этапе проектирования, и для описания разрабатываемой системы.
Графические модели становятся частью проектной документации.

По поводу и графического моделирования, и подхода с добротной документацией в отрасли есть разные мнения. Одни не представляют без этого работы (и таких всё больше, особенно по мере улучшения уровня обучения в ВУЗах), другие говорят (и тоже из реального опыта): "нет толку от этого документирования, отнимает кучу времени поддержание актуальности, код уходит вперёд" и т.п. В отрасли есть примеры и того, как загибаются проекты, не имеющие нормальной документации (так будет рано или поздно с любым проектом, если только он не ведётся всё время одной и той же малой командой или вообще человеком, которые держат всё знание в головах). Если и примеры, как при обилии документации проект оказывается провальным. Это означает, что документировали не то, что нужно, или просто не смогли реализовать напроектированное.

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

Далее начинаются разногласия относительно графических методов в программировании и в проектировании. Есть языки графического программирования (LabView, реализации ДРАКОНа, Microsoft Robotics Studio, Scratch - хотя он не визуальный, а типа визуализованного текта...), есть их сторонники и противники, и есть языки графического проектирования-моделирования (от простейших - ER-диаграммы, до претендующего на универсальность UML - Universal Modelling Language. В дообъектную эпоху были распространены IDEF и SADT-диаграммы). Противники графического моделирования предлагаются ограничиваться неформальными описаниями на естественном языке, таблицами, неформальными иллюстрациями.

Какие факты имеют место быть:
1) Доказано, что хорошую, специально подготовленную графику мозг воспринимает лучше, чем текст - быстрее и т.п. Хотя есть процентов 15-20 людей, у которых может быть и наоборот. Однако если графика очень продуманная и строгая, то и у них она воспринимается, по крайней мере, не хуже, чем текст.
2) В большом числе случаев графику используют неправильно, недостаточно лаконично, выразительно, строго, не накладывают на неё строгие правила. Это и для мозга не так удачно, и ещё и вызывает неприятие у многих "умных людей".
3) Подготавливать графику труднее, чем текст, если нет специальных программных средств. Требования к инструментальному оснащению возрастают.
4) Свобода рисования оказывается часто недостатком. Сколько рисовальщиков схем - столько и вариантов. Сидишь и "чешешь репу", что поместить справа, а что слева, и под каких углом провести линию.

Это и затрудняет распространение графики. Для программирования переход на графику будет ещё долгим и только частичным. Скорее там восторжествуют вместо плоского текста "семантические редакторы" - когда редактируем дерево программы, видим всякие активные таблички, формируем программу блоками.
Но для моделирования хорошие графические языки - то, что надо.
Главное - правильно их использовать. Документация - это сама по себе всего лишь модель системы, она не должна быть чрезмерно детальной. А графическая модель - это уже самый "экстракт", самое главное из документации.
- изображайте самое главное, стрежневое;
- поддерживайте рисунки простыми;
- используйте строгие визуальные языки, если берёте большой раздутый язык типа UML, то берите небольшое подмножество.
И "будет щаЗтье".

В ПО есть две стороны, как известно: алгоритмы (поведение, процессы) и данные. ООП немного изменило ситуацию в том плане, что алгоритмы "растеклись" по данным, стали привязанными к данным. Это ещё больше повысило значение языков моделирования данных.

Т.е., имея язык моделирования алгоритмов (процессов) и язык моделирования структуры данных (соответствующий реалиям ООП), мы имеем полноценный арсенал визуального моделирования ПО.

Древний и простой визуальный язык моделирования алгоритмов - блок-схемы. Однако они имели много недостатков, почему от них все здравые люди отказались (хотя ГОСТ на них есть - и иногда по ГОСТу требуется формализовать алгоритмы блок-схемами, в частности, в курсовых и дипломных УНИИТ ГУ-УНПК). Сейчас большую популярность набирает пришедший из космической отрасли ДРАКОН - это язык изображения алгоритмов, ориентированный на 1) максимальное удобство для восприятия и 2) максимальное "ограничение свободы рисования". Т.е. это не рисунок, а некая жёсткая конструкция, построенная по строгим правилам.

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

Вот и получается, что если взять ER-диаграммы, сущности описывать объектно-ориентированно - и изображать отношения обобщения (наследования), то мы получаем минимальный джентльменский набор для моделирования данных.
Учитывая, что в объектной системе и поведение рассредоточено по данным, то мы имеем основной инструмент описания структуры системы.

UML пошёл путём введения своих правил изображения классов, их отношений и особенностей, дополнил их другими видами диаграмм: как поведенческих (диаграммы взаимодействия, диаграммы деятельности), так и всяких вспомогательных (типа диаграммы пакетов, диаграммы способа использования) - и в нём получилось как некое базовое хорошее ядро (диаграммы классов, диаграммы взаимодействия классов) - которое используется повсеместно, в том числе в массе литературы, так и всякий необязательный мусор, который на практике удобнее описать текстовой документацией.
Ничего сложного в UML нет, пока он используется как язык документирования и проектирования.
Уже 20 лет безуспешным попыткам превратить UML в язык программирования - и генерировать код по диаграммам. Они провальны, потому что это менее удобно, чем писать код. А модель на то и модель, чтобы не было нужды детально прописывать каждую мелочь.
Ввиду того, что на практике нужно всё время только подмножество UML, трудно найти удобную программу, которая не содержала бы излишеств и т.п.

Мы будем использовать программу DRAKON Editor Степана Митькина, в которой с определённого момента в дополнение к ДРАКОНу появился свой визуальный язычок моделирования данных, названный ERIL (Entity-Relation & Inheritance Language - "язык для отношений сущность-связь и отношений наследования"). Собственно, он как раз и сделан по вышеописанной мысли дополнения ER-диаграмм, плюс содержит строгие правила, как их рисовать, плюс поддержан удобной и простой программой.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 18 Февраль, 2014 11:15 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8904
Откуда: Россия, Орёл
И в тему - 5-страничная выдержка из Эванса "Предеметно-ориентированное проектирование", касательно места и роли UML в проектировании и документации.


Вложения:
DDD о документации и UML.pdf [1.46 МБ]
Скачиваний: 123
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 18 Февраль, 2014 13:07 

Зарегистрирован: Суббота, 16 Февраль, 2008 07:58
Сообщения: 312
Откуда: Россия, Стерлитамак
Спасибо и Спепану Митькину, и за перевод (без него хуже идею уловил)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 21 Февраль, 2014 15:42 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 9
Спасибо за поддержку!

Кроме графики, в языке ERIL имеется содержательная часть. Это касается генерируемого кода.
1. Гарантируется целостность ссылок. Как внешние ключи в базах данных.
2. Гарантируется целостность по части уникальных полей. Как индексы в базах данных.
3. Генерируется скучный, однообразный, но нужный код: функции сравнения, хэш-функции, автоматическое поддержание индексов.
4. В принципе, можно сгенерить и любой другой унылый, но необходимый код:
- сериализация всех мастей, в том числе в XML и в SQL.
- графический интерфейс пользователя

Достигаемые цели:
1. Меньше ошибок.
2. Меньше вручную написанного кода.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 22 Февраль, 2014 07:43 

Зарегистрирован: Суббота, 16 Февраль, 2008 07:58
Сообщения: 312
Откуда: Россия, Стерлитамак
Степан Митькин писал(а):
- сериализация всех мастей, в том числе в XML и в SQL.

Я правильно понял, что запросы скль можно будет делать рисуя графики?
Если да, то насколько сложные? Или абсолютно любые?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 22 Февраль, 2014 13:42 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1526
Откуда: Беларусь, Минск
Я так понял, что не запросы к БД, а саму БД.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 25 Февраль, 2014 22:18 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8904
Откуда: Россия, Орёл
Хм, в архиве, который я выкладывал, статья открывается без картинок.

Исправляюсь.


Вложения:
ERIL.7z [437.47 КБ]
Скачиваний: 151
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 26 Февраль, 2014 16:38 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8904
Откуда: Россия, Орёл
Использовали со студентами ERIL, чтобы описать уже разработанную в прошлом семестре системку - поисковик по текстовым файлам.

Применили три типа диаграмм:
- связи импорта модулей (1:1, атрибутом связи можно помечать, если модуль использует только небольшую часть сущностей импортируемого модуля).
- диаграмма структур данных одного из модулей. Тут возникли нюансы, что когда используем связанный список в стиле ББ, один и тот же тип данных может обозначать в коде и элемент этого типа, и сам тип. При моделировании это нужно учитывать. Пока написали СПИСОК ИЗ..., а так можно для КП ввести какое-нибудь соглашение, что если тип данных используется как список, то ставить, допустим, звёздочку после него...
- и совсем нелегальное использование выразительных средств ERIL-а: забабахали диаграмму последовательности взаимодействия (sequence diagram из UML).
К Степану просьба: посмотреть и заценить такое примение, может быть, "легализовать" его, а то потом в следующих версиях редактора будет какое-нибудь ограничение, что такое не нарисуешь :)

Вложение:
1 - диаграмма импорта.png
1 - диаграмма импорта.png [ 67.99 КБ | Просмотров: 4333 ]


Вложение:
2 - диаграмма данных Index.png
2 - диаграмма данных Index.png [ 47.65 КБ | Просмотров: 4333 ]


Вложение:
3 - диаграмма последовательности.png
3 - диаграмма последовательности.png [ 58.12 КБ | Просмотров: 4333 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 26 Февраль, 2014 16:42 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8904
Откуда: Россия, Орёл
Пояснения на занятии по диаграмме модулей

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

Сам модуль - это набор деклараций (константы, типы), свойств (переменные) и операций (процедуры). Т.е. это почти то же, что сущность (класс), только плюс декларации, и кроме того, он существует в системе в единственном числе.
Логично, что модуль можно изобразить таким же прямоугольником, как и сущность (класс).

Внутри прямоугольника можно перечислить экспортированные из модуля декларации, свойства и операции. Если модулей немного, то можно нарисовать одной диаграммой и связи, и содержимое модулей. Если же много, то вспоминая правила ERILа, мы рисуем заполненные модули отдельно, а потом на диаграмме импорта оставляем только прямоугольники с названиями.

Ищем среди модулей Kurs13SearchXXXX те, которые не импортируют никого из этой же подсистемы.
1 уровень: Kurs13SearchIndex
Ищем те модули, которые импортируют только SearchIndex.
2 уровень: Kurs13SearchAnalyzer, Kurs13SearchCmds
3 уровень: Kurs13SearchScanner
4 уровень: Kurs13SearchUIIndex

В ББ есть не очень удобный, но иногда полезный инструмент - схема зависимостей модулей. Выделите список модулей и нажмите Info-Dependencies.
Kurs13SearchIndex
Kurs13SearchAnalyzer Kurs13SearchCmds
Kurs13SearchScanner
Kurs13SearchUIIndex

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

Для модуля создаём прямоугольник "Сущность с полями". В заголовке пишем MODULE SearchIndex.
А внизу - то, что он экспортируем. Процедуры пишем без слова PROCEDURE. Для параметров в большинстве случаев не имеет смысл указывать базовые типы (ARRAY OF CHAR, INTEGER). Будем указывать тип параметра, либо когда он неочевиден, либо когда это уже наш тип, а не базовый языковый.

Модуль SearchUIIndex содержит много экспортированных элементов - для подключения формы, а интересность архитектурная у них маленькая.
Поэтому в диаграмме связей мы отобразим только прямоугольник с названием, а раскроем его рядом.

Поскольку направление связей импорта очевидно (сверху вниз), то стрелка избыточна, достаточно линии. Кроме того, модули все в единственном экземпляре, т.е. связь импорта всегда один-к-одному, а это в ERIL именно прямая линия.
На связях импорта значком атрибутов изобразим то, что именно используется конкретным модулем-импортёром из импортируемого модуля. Конечно, если какой-то модуль использует почти всё из импортируемого, то нет никакого смысла это перечислять на связи.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 26 Февраль, 2014 16:45 
Модератор
Аватара пользователя

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

Цитата:
Создадим диаграмму для структуры данных модуля Index.
Очевидно, что самой главной сущностью, владельцем, является сам модуль.
Важно: здесь модуль является сущностью и владельцем, потому что у него есть переменные, через и идёт доступ к данным. Т.е. тут модуль является как бы и объектом, в единственном экземпляре.
А вот модули Dogs, Lamps, Arrows из предыдущего ООП-примера не являются сущностями - они не хранят в себе данные и не занимаются управлением созданными объектами. Они всего лишь хранят описания типов данных.

Итак, вверху нашей диаграммы - сущность модуль Index. Какие переменные модуля мы на ней отразим? currentDoc можно не отражать, он не существенен для понимания структуры данных, он имеет чисто служебное значение для процедур.
А wordsTable и allDocuments - существенны.

Но! Мы должны понимать, что элемент массива - это не отдельная сущность Word, это список сущностей Word. Особенность реализации - что этот список никак явно не именуется (мы не вводим тип данных WordList, и т.п.) И у нас переменная типа Word всегда может обозначать как указатель на отдельное слово (сущность Word), так и указатель на список слов (не названная в программе явно сущность "связанный список из Word").
wordsTable: ARRAY 60*60*60 OF Word,
где элемент - связанный список из Word
allDocuments: Document
связанный список из Document

Строим связь один-ко-многим одноправленную от сущности модуля к сущности СПИСОК ИЗ Word. Атрибут связи со стороны модуля (т.е. через что идёт связь) - переменная wordsTable.

Дальше связь один-ко-многим однонаправленную от сущности СПИСОК ИЗ Word к сущности Word. Связь в списке осуществляется через поля next.

У сущности Word отражаем её поля. Если бы их было много, мы бы что-то не показывали, но раз их немного, то можно все. Кроме поля next, которое, вообще говоря, относится к концепции списка, а не самой сущности Word.

Есть соблазн не отражать на диаграмме отдельно сущность DocLink. Типа, это всего лишь частная реализация связи один-ко-многим от Word к Document.
Но! Эта сущность может становиться важной, если мы будем развивать систему. Мы можем захотеть хранить информацию о местах вхождения слова в документ (чтобы сразу показывать и подсвечивать, например, и т.п.) - и всё такая доп. информация о вхождении слова окажется в сущности DocLink.
Поэтому прорисуем эту сущность, как подчинённую к Word.

Мы встретились как раз с тем случаем, о котором сказано в документации ERIL: когда связь "один-ко-многим" является односторонней со стороны DocLink. Т.е. DocLink ссылается на единственный Document. Получается, что на Document ссылается много DocLink-ов. Но узнать для Document множество этих DocLink-ов нельзя, оно не хранится. Поэтому получается, связь односторонняя - и изобразили мы её стрелкой, а не "лапой".

Мы строили диаграмму по коду, как иллюстрацию кода, поэтому она недостаточно абстрактна, содержит детали реализации на конкретном языке.
Если бы мы сначала проектировали модель данных, а потом по ней реализовывали на конкретном языке, то у нас бы была более "чистая" модель. Она бы переводилась на конкретный язык различным образом: допустим, при реализации на Java мы бы использовали не связные списки, а контейнеры ссылок на объекты.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 26 Февраль, 2014 16:56 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8904
Откуда: Россия, Орёл
Пояснения по диаграмме взаимодействия

Цитата:
Диаграммы последовательности взаимодействия
Это вид диаграмм из UML-я (sequence diagram). В ERIL он явно не введён, но из доступных элементов такие диаграммы можно нарисовать.
Задача диаграмм последовательности - показать, в каком порядке и какие сущности друг к другу обращаются, посредством вызова процедур.
Момент возврата из процедур мы рисуем прямой линией без стрелок.
Когда мы второй раз изобразили тот же вызов AnalyzePart, мы его, конечно, не раскрываем подробно, но пачку стрелочек нарисовали.
Вот явная польза таких диаграмм: достаточно тонкий момент, что последнее слово добавляется в индекс не AnalyzePart-ом, а EndDocument-ом, здесь виден как на ладони.

Можно с помощью таких диаграмм раскрыть и другие вызовы, но вот эта цепь для IndexFile самая сложная и неочевидная.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 03 Июнь, 2016 18:36 
Аватара пользователя

Зарегистрирован: Пятница, 11 Май, 2007 21:57
Сообщения: 974
Откуда: Украина, Киев
Это всё конечно хорошо, но отсутствие русскоязычной версии описаний... по меньшей мере, факт странный.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 03 Июнь, 2016 19:58 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 332
Откуда: Москва
Ярослав Романченко писал(а):
Это всё конечно хорошо, но отсутствие русскоязычной версии описаний... по меньшей мере, факт странный.

Согласен с Вами. Ярослав, Вы конечно правы. Русский текст необходим как воздух. Почему же его нет?

Причина проста. Степан Митькин живет и работает в Норвегии, город Осло. Он ориентируется на англоязычную аудиторию, а это очень важно.
На русский язык у него просто не остается времени. Ему, разумеется, нужна помощь.

В свое время такую помощь оказал Александр Ильин (спасибо ему). Благодаря Ильину мы имеем перевод на русский язык ДРАКОН-редактора Митькина (версия rus).
Цитата:
Авторы

Степан Митькин и Александр Ильин.
См. http://drakon.su/drakon_editor в самом низу.

Что касается языка ERIL, то пока еще никто не собрался и не помог с переводом на русский.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 03 Июнь, 2016 20:18 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8904
Откуда: Россия, Орёл
Владимир Паронджанов писал(а):

Что касается языка ERIL, то пока еще никто не собрался и не помог с переводом на русский.


Так эта ветка начата как раз архивом перевода документации ERIL на русский.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 15 ] 

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


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

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


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

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