Глава 17. Метрики, макеты и спецификации

• Разработка метрик проектирования и генерации модулей
• Изгнание мегамодулей
• Пакетная обработка
• Отчеты
• Оперативные приложения
• Следует ли выполнять макетирование?
• Макетирование средствами УРП
• Макетирование при разработке без использования средств УРП
• Где мои спецификации? Принципы разработки спецификаций модулей
• Описание экранных форм и отчетов
• Описание пакетных процессов

В процессе проектирования любой системы наступает момент, когда руководитель проекта начинает преследовать вас вопросами наподобие следующих: "Сколько времени понадобится на генерацию этих модулей?", "Какими средствами вы будете пользоваться для их генерации?" И это еще в лучшем случае. Если же вам не повезет, то руководство к этому моменту уже ответит на эти вопросы к своему полному удовлетворению и перед вами встанет воистину невыполнимая задача — сделать так, чтобы предсказания руководства сбылись! (В этой главе мы попытаемся помочь вам справиться с этой задачей.)

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

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

Эта глава посвящена основам "черной магии" проектирования кода — оценке трудоемкости, составлению спецификаций и макетированию.

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

В большинстве качественно выполняемых проектов оценку времени производят дважды:

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

Составьте предварительный перечень модулей, выберите средства, при помощи которых их нужно реализовать (на данном этапе это ни к чему не обязывает), назначьте каждому модулю средство и укажите сложность. Не изобретайте восемь или девять уровней сложности, а используйте максимум четыре:

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

Что же такое метрики? Это просто таблицы плановой трудоемкости (в человеко-днях) для каждого уровня сложности и каждого средства разработки которое будет использоваться при программировании. В табл. 17.1 мы разбили метрики на три задачи: проектирование программы, генерация и автономное тестирование.

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

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

Итак, теперь у нас есть предварительный список модулей, перечень продуктов, с помощью которых мы рассчитываем их реализовать, и ориентировочные сроки их разработки.

В следующих разделах мы опишем, в каких формах проявляется влияние мегамодулей. Грустно, но мегамодульная экранная форма, или форма-супермен, — весьма распространенная особенность интерактивных систем. В этих случаях часто обнаруживается, что одной формой поддерживается несколько прикладных функций. Например, в одном знаменитом приложении на базе Oracle Forms нам посчастливилось быть свидетелями того, как все DML-операции (кроме операций сопровождения справочных таблиц) содержались в одном триггере ON-COMMIT дьявольской сложности. В качестве оправдания говорилось, что так нужно пользователям. Однако причиной появления одного из нас на этом узле являлись постоянные жалобы пользователей на плохую производительность и недостаточную надежность этой экранной формы. В результате первым этапом нашей работы стало выяснение того, что пользователи хотят, чтобы приложение работало не так. Другой случай: один гордый разработчик показал нам приложение, разработанное в одной форме Oracle с 70 экранными страницами!

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

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

Ключ к реализации такого задания — построение управляющей структуры для основного цикла и последующее жесткое отделение (инкапсуляция) каждого действия, выполняющегося на каждой итерации цикла. Это позволяет модифицировать только одно из действий без воздействия на остальные. Для программиста может быть совершенно очевидно, что шаг 24 выполняется только в тех случаях, когда на шаге 17 выполняется определенное условие. Однако всем заинтересованным лицам (и особенно группе обслуживания) будет гораздо легче жить, если вы не обеспечите полную оптимизацию и не сделаете так, что шаг 17 оставит свое заключение в каком-то потайном месте, откуда его сможет взять шаг 24. Самое простое решение — заставить и шаг 17, и шаг 24 проверять базу данных на предмет выполнения вышеупомянутого условия (если повезет, то весь требуемый SQL-код и данные будут еще находиться в SGA). Если из-за того, что на этих шагах теперь приходится выбирать одни и те же данные для принятия того же самого решения, возникает серьезная проблема с эффективностью, то принятие этого решения следует инкапсулировать в процедуру, которая будет регистрировать (незаметно для этих шагов) факт выполнения необходимой обработки.

Что касается отчетов, то, как правило, легче просто создать несколько похожих отчетов, чем пытаться построить один отчет, который настраивается под все возможные требования путем непрерывного добавления новых параметров. В самом деле, если мы предположим, что отчеты запускаются не по имени, а при помощи пункта меню или каким-то другим способом из ГПИ, то пользователю все равно, каким числом модулей поддерживается отчет — одним или сотней. Большое преимущество этого подхода в том, что если пользователь захочет внести изменение в формат заголовка одного отчета, то (если ему повезет) этот заголовок изменится только в этом отчете и ни один из остальных отчетов не прекратит работу. Большинство средств генерации отчетов позволяет разрабатывать библиотеки, которые могут совместно использовать модули отчетов, поэтому такой подход не обязательно подразумевает невозможность многократного использования.

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

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

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

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

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

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

Горячие споры о макетировании приложений ведутся уже много лет. Стоит ли макетировать? Какие цели при этом достигаются? Не задают ли макеты неприемлемо высокие уровни пользовательских ожиданий? Что делать с макетом — выбросить или, доработав, включить в состав системы? Не слишком ли это трудоемкое занятие?

Мы попробуем ответить на эти вопросы. Но сначала нужно провести различие между двумя типами макетов. Традиционно макет был средством испытания той или иной концепции либо демонстрации той или иной возможности пользователям и получения обратной связи. Такие макеты практически всегда были одноразовыми и после утверждения выбрасывались. При использовании методов ускоренной разработки приложений (УРП) макет после нескольких итераций в итоге становится частью промышленной системы (если не всей системой).

Достоинство метода УРП состоит в том, что мы не теряем время на создание того, что потом придется выбросить. Кроме того, мы, как правило, получаем работающую модель, а не ряд пустых экранных форм, не поддерживающих какие-либо функции. Мы испытываем процесс, а не просто демонстрируем экранные формы, которые являются не более чем схемами. При всех своих достоинствах метод УРП обладает рядом значительных недостатков, среди которых можно назвать следующие:

Проектировщики должны при разработке макетов постоянно помнить обо всех этих недостатках. Необходимо совершенствовать свои навыки генерации, потому что проектирование и генерация при разработке средствами УРП тесно переплетены. Вряд ли имеет смысл производить все итерации отдельно, а затем передавать результаты для генерации окончательного варианта, ведь на этот момент будет выполнено 90% всего объема работы.

Если вы хотите больше узнать о том, как корпорация Oracle относится к использованию УРП в среде Oracle, почитайте книгу CASE Methods FastTrack: A RAD Approach (Dai Clegg, Richard Barker. Addison Wesley, 1994).

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

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

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

При демонстрации и обсуждении макета с пользователями особенно важно правильно установить основные правила и уровни ожидания. Необходимо постараться, чтобы у пользователей не создалось ложное впечатление. Некоторые макеты выглядят почти так же, как завершенная система, хотя на самом деле являются лишь ничем не заполненной оболочкой. Если показать такой макет пользователям и плохо все объяснить, то они могут уйти в надежде получить готовую систему через пару недель! Хорошая демонстрация любой вещи может обеспечить вам сделку!

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

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

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

Взгляните критически на систему и определите, где у нее самые сложные участки и самые узкие места с точки зрения достижения общего успеха. Если вообще не ясно, как они будут реализованы, составьте список альтернативных вариантов и попробуйте реализовать их. Этот процесс может занять достаточно много времени, поэтому прибегать к этому методу следует лишь в случае, если будет достигнута какая-то ощутимая выгода с точки зрения производительности или практичности конечной системы. Нужно реально смотреть на вещи. Вполне вероятно, что для самой сложной проблемы в приложении существует несколько решений. Выберите два, максимум три, подхода, которые кажутся наиболее вероятными, и отмакетируйте их, поскольку в противном случае вы создадите две-три законченные прикладные системы — а это как раз то, чего вы стараетесь избежать. (Помните, что назначение макетов — избежать дорогостоящих ошибок.)

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

Завершая наш разговор о макетах, воспользуемся словами из рекламы фирмы Nike — Just Do It! ("Сделайте же это!") Записки, спецификации и электронно-почтовые сообщения не очень помогают, когда приходится объяснять свои предложения пользователям и пытаться привлечь их к процессу разработки. Создание же макета — стоящее дело, особенно если этот макет относительно невелик в сравнении со всей системой. Может быть, стоит даже получить формальное одобрение результатов макетирования со стороны участвующих в проекте пользователей.

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

Кто будет генерировать эти модули? Вполне возможно, что вы как проектировщик приложения будете также генерировать входящие в него модули. В этом случае у вас может возникнуть желание написать краткую спецификацию и как можно скорее приступить к программированию или сначала создать модуль, а потом уже написать спецификацию (или вообще не писать ее!). Это искушение особенно сильно при разработке средствами УРП.

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

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

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

Псевдокод — это катастрофа. По самой своей природе он диктует структуру реального кода и не позволяет разработчику действовать самостоятельно. Он очень подвержен ошибкам, как синтаксическим, так и логическим. Его нельзя проверить на правильность синтаксиса, его нельзя скомпилировать, запустить, и, следовательно, протестировать.

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

Если вам требуется представить алгоритмы, делайте их в общем виде. Единственное (небесспорно) допустимое исключение — спецификация какого-либо сложного математического расчета с массой зависимостей между шагами, где нельзя выразить расчет достаточно точно без применения формального языка. Используйте алгоритм, но обеспечьте его синтаксическую проверку, выполнение в своей среде, тестирование и передайте в форме, позволяющей программисту инсталлировать его на своей рабочей станции. Другими словами, если вы решили программировать сами, доведите эту работу до конца и передайте результат компоновщикам для интеграции.

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

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

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

Пример 17.1. SQL-предложение, замаскированное под описательный текст, в фрагменте спецификации

В примере 17.2 показан еще один вариант — трата времени и бумаги на то, чтобы рассказать разработчикам о том, чего им объяснять не нужно. Программисты, работающие с 3GL, знают, что для обработки наборов данных создается цикл и что в конце цикла нужно дать программе указание выйти из цикла и сделать что-то еще. Если же вам приходится объяснять программистам такие вещи, это значит, что вам нужны не длинные спецификации, а другие программисты.

В хорошей спецификации модуля должны быть перечислены таблицы и столбцы, к которым производится доступ, и указано, какие столбцы запрашиваются, вставляются, обновляются и удаляются, а какие — используются в условиях WHERE. Как мы уже упоминали, эту структуру иногда называют CRUD-матрицей, поскольку в ней указываются столбцы, данные в которых будут создаваться (CREATE), читаться {READ), обновляться (UPDATE) и удаляться (DELETE). Большинство CASE-средств, поддерживающих определение модулей, рассчитаны на получение информации такого рода и, как правило, содержат средства для ее ввода. Огромное достоинство этих матриц (особенно при использовании CASE-средств) состоит в том, что они позволяют оценить предлагаемые изменения в БД, обратившись к спецификации модуля и посмотрев, какие модули это изменение затронет.

Наконец, следует пересмотреть спецификацию каждого модуля в свете всех проектных решений и стандартов. Необходимо учесть взаимодействие между модулем и правилами, введенными как объекты базы данных, причем особый акцент следует сделать на обеспечении нормального интерфейса с пользователем. Например, приемлемо ли для пользователя потратить пару минут на ввод данных лишь для того, чтобы все они были при фиксации отклонены с сообщением Check constraint SYS_00023 violated? Вероятно, нет. Приемлемое решение, наверное, предусматривает ряд шагов и, возможно, включает шаблон кода для обработки ошибок, генерируемых ПО Oracle Server.

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

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

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

Когда речь идет о пакетных процессах, основная часть описания касается обработки. Однако не следует забывать и о таких элементах, как:

Более подробно пакетная обработка рассматривается в главе 20.

НОВОСТИ ФОРУМА Рыцари теории эфира

10.11.2021 - 12:37: ПЕРСОНАЛИИ - Personalias -> WHO IS WHO - КТО ЕСТЬ КТО - Карим_Хайдаров. 10.11.2021 - 12:36: СОВЕСТЬ - Conscience -> РАСЧЕЛОВЕЧИВАНИЕ ЧЕЛОВЕКА. КОМУ ЭТО НАДО? - Карим_Хайдаров. 10.11.2021 - 12:36: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ - Upbringing, Inlightening, Education -> Просвещение от д.м.н. Александра Алексеевича Редько - Карим_Хайдаров. 10.11.2021 - 12:35: ЭКОЛОГИЯ - Ecology -> Биологическая безопасность населения - Карим_Хайдаров. 10.11.2021 - 12:34: ВОЙНА, ПОЛИТИКА И НАУКА - War, Politics and Science -> Проблема государственного терроризма - Карим_Хайдаров. 10.11.2021 - 12:34: ВОЙНА, ПОЛИТИКА И НАУКА - War, Politics and Science -> ПРАВОСУДИЯ.НЕТ - Карим_Хайдаров. 10.11.2021 - 12:34: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ - Upbringing, Inlightening, Education -> Просвещение от Вадима Глогера, США - Карим_Хайдаров. 10.11.2021 - 09:18: НОВЫЕ ТЕХНОЛОГИИ - New Technologies -> Волновая генетика Петра Гаряева, 5G-контроль и управление - Карим_Хайдаров. 10.11.2021 - 09:18: ЭКОЛОГИЯ - Ecology -> ЭКОЛОГИЯ ДЛЯ ВСЕХ - Карим_Хайдаров. 10.11.2021 - 09:16: ЭКОЛОГИЯ - Ecology -> ПРОБЛЕМЫ МЕДИЦИНЫ - Карим_Хайдаров. 10.11.2021 - 09:15: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ - Upbringing, Inlightening, Education -> Просвещение от Екатерины Коваленко - Карим_Хайдаров. 10.11.2021 - 09:13: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ - Upbringing, Inlightening, Education -> Просвещение от Вильгельма Варкентина - Карим_Хайдаров.