Преглед изворни кода

Merge branch 'master' of http://213.155.192.79:3001/ypv/ISRPO

ypv пре 1 година
родитељ
комит
2283e06ba9

+ 155 - 0
Лекции/3d_Modeling/3d_Modeling_LVS.md

@@ -0,0 +1,155 @@
+**3D-Моделирование**
+
+3D-моделирование -- это построение модели объекта в трехмерном
+пространстве. Данный способ представления объектов начал применяться в
+1960-х годах, когда этим занимались специалисты компьютерной инженерии.
+Современные технологии 3D-моделирования позволяют конструировать сложные
+и объемные модели, проводить тестирование и вносить в них изменения на
+различных уровнях.
+
+Хотя программное обеспечение для 3D-моделирования основано на сложных
+математических расчетах, все вычисления проводятся автоматически с
+предоставлением удобного пользовательского интерфейса. Создание
+трехмерной модели довольно затруднительно и представляет собой своего
+рода искусство. Для достижения реалистичности необходимо разбираться в
+особенностях моделирования и правильно проводить расчеты в течение всего
+процесса моделирования.
+
+**Преимущества** **3D-Моделирования**
+
+Системы 3D-моделирования позволяют получить модель объекта еще до
+изготовления пробных образцов и, следовательно, разглядеть слабые
+стороны проекта и определить его соответствие первоначальной задумке.
+
+Еще одним, но также довольно существенным плюсом 3D-моделирования
+является крайняя степень убедительности и наглядности трехмерных
+картинок и видео. Если следовать утверждению, что лучше один раз
+увидеть, чем тысячу раз услышать, то презентация в 3D длительностью 30
+секунд дает тот же результат, что и двухчасовое выступление.
+
+Чтобы получить представление о внешнем виде будущего здания на основе
+одних лишь зарисовок, нужно иметь хорошее воображение. Намного большего
+эффекта можно достичь благодаря технологиям трехмерной графики, которые
+позволяют увидеть итоговый результат проекта еще на стадии разработки.
+
+**Сферы применения 3D-Моделирования**
+
+Создание виртуальных миров и вымышленных персонажей стало возможным
+благодаря особой технике использования полигонов. Они представляют собой
+простые геометрические фигуры с тремя или четырьмя гранями, образующие
+путем соединения под разными углами один объект.
+
+Чем меньшую площадь занимает каждый отдельный сегмент, тем их больше в
+совокупности, а значит, больше четкость изображения. Здесь используется
+такое понятие как качество графики -- в различных играх ее можно
+регулировать. Это имеет смысл тогда, когда компьютер не обладает
+достаточными ресурсами для быстрого отображения всех фрагментов.
+
+**- Сфера медицины:**
+
+Благодаря 3D-сканированию сейчас удается обнаружить повреждения органов
+и тканей, которые невидимы для обычного рентгеновского аппарата.
+Подобные технологии дают возможность установить точный диагноз тогда,
+когда это не получалось сделать при предыдущих обследованиях. Они
+находят широкое применение в стоматологии и челюстно-лицевой хирургии. В
+дополнение к виртуальным макетам при внедрении новых технологий многие
+учреждения здравоохранения приобретают также специальные 3D-принтеры.
+
+**- Промышленное проектирование**
+
+Основная потребность в этом возникает у специалистов из технических
+областей -- инженеров, электриков, строителей и т.д. Они работают с
+твердотельными или полыми объектами, характеристики которых имеют строго
+определенное значение.
+
+Соответственно, для этой группы пользователей важно в первую очередь не
+изобразить модель, а тщательно все рассчитать с применением формул,
+разработать чертежи и осуществлять контроль в ходе всего проектирования.
+Другими словами, их основная цель -- не визуальное представление
+объекта, а получение конкретных сведений о нем.
+
+Поэтому необходимое программное обеспечение с широким функционалом и
+большим набором инструментов компании приобретают с расчетом на весь
+отдел. Также оно используется для обучения в технических и архитектурных
+вузах, чтобы выработать у студентов навыки конструирования в комфортной
+среде.
+
+**Этапы 3D-Моделирования**
+
+-   **Создание геометрии модели**
+
+На первом этапе создается пространственная геометрическая модель
+объекта, не учитывающая его физические характеристики. Производятся
+расчет размеров и построение формы предмета. Используются методы
+вращения, выдавливания, наращивания, полигонального моделирования.
+
+-   **Создание текстуры объекта**
+
+На данной стадии определяется, из каких материалов будет построен
+объект, разрабатывается его текстура. Именно в этот момент задается
+степень реалистичности создаваемой модели.
+
+-   **Выбор освещения**
+
+На данном этапе возникают сложности, поскольку от указанных параметров
+зависит восприятие модели, насколько она будет правдоподобной.
+Указываются тон освещения, степень яркости, резкости, насыщенность
+теней.
+
+-   **3D-визуализация или рендеринг**
+
+На заключительной стадии 3D-моделирования осуществляется уточнение
+настроек отображения модели, в частности, добавление специальных
+эффектов вроде бликов, тумана и т.д. При наличии анимации корректируются
+ее параметры. Также определяются параметры визуализации (число кадров в
+секунду, формат конечного видео). Если в результате получается
+двухмерное изображение, следует выбрать его формат и разрешение.
+
+-   **Постпродакшн**
+
+По окончании процесса 3D-моделирования в готовый материал можно включить
+спецэффекты с использованием программных средств, таких как Adobe
+Photoshop, Adobe Premier Pro, Adobe Illustrator и т.д. Другими словами,
+происходит постпродакшн, когда итоговый результат улучшается с
+применением различных технологий.
+
+**Модули визуализации в 3D-Моделировании**
+
+### **Scanline**
+
+Сканлайн рендер благодаря своей скорости применяется в видеоиграх и
+интерактивных сценах. При наличии мощного видеоадаптера с его помощью
+можно получить четкое изображение с частотой больше 30 кадров в секунду.
+
+Действие рендера основано на реализации принципа «ряд за рядом». Вначале
+необходимые полигоны располагаются по наибольшей вертикальной
+координате. После этого каждый ряд изображения формируется посредством
+пересечения с ближайшим к виртуальной камере полигоном. В процессе
+перехода между рядами происходит удаление полигонов, которые исчезают из
+поля зрения.
+
+### **Raytrace (метод трассировки лучей)**
+
+Целью данного метода является получение изображения с максимальным
+разрешением подробной детализацией. При этом рендеринг занимает много
+времени и не подходит для создания анимированной графики в реальном
+времени.
+
+При использовании рейтрейс-метода от виртуальной камеры для каждого
+пикселя на воображаемом экране проводятся лучи до ближайшего трехмерного
+объекта. Цвет точки определяется исходя из того, с каким объектами
+сталкивается воображаемый луч.
+
+### **Raycasting (метод бросания лучей)**
+
+При этом способе происходит то же самое, что и в предыдущем случае, но
+здесь рассчитывается только первая поверхность, на которую упадет луч. В
+зависимости от характеристик объекта и освещенности определяется цвет
+пикселя изображения. Дальнейшая обработка отраженных от объекта лучей в
+таком случае не происходит.
+
+Освоение трехмерной графики приводит в движение целые направления в
+промышленности, а также приносит динамику в нашу жизнь. Нельзя
+сомневаться, что будущее 3D-моделирования ничем не ограничено, что эти
+передовые технологии скоро увеличат свою доступность, востребованность и
+незаменимость!

+ 128 - 0
Лекции/Unit_тесты/Unit_Tests_LVS.markdown

@@ -0,0 +1,128 @@
+**Unit-Tests**
+
+До запуска приложения в производство, когда оно станет доступно
+пользователям, важно убедиться, что данное приложение функционирует, как
+и должно, что в нем нет ошибок. Для проверки приложения мы можем
+использовать различные схемы и механизмы тестирования. Одним из таких
+механизмов являются юнит-тесты.
+
+Юнит-тесты позволяют быстро и автоматически протестировать отдельные
+компоненты приложения независимо от остальной его части. Не всегда
+юнит-тесты могут покрыть весь код приложения, но тем не менее они
+позволяют существенно уменьшить количество ошибок уже на этапе
+разработки.
+
+Мы не должны тестировать код используемого фреймворка или используемых
+зависимостей. Тестировать надо только тот код, который написали мы сами.
+
+Надо отметить, что в целом концепция юнит-тестов не является непреложным
+требованием к веб-разработке, да и вообще к разработке. Кто-то считает,
+что юнит-тесты обязательно должны покрывать весь код проекта, кто-то
+полагает, что юнит-тесты можно использовать преимущественно для особо
+сложных моментов в коде приложения, какой-то сложной логики. Некоторые
+не используют юнит-тесты.
+
+Но тем не менее юнит-тесты несут потенциальные преимущества при
+разработке, к которым следует отнести не только собственно проверку
+результата и тестирование кода, но и другие, как например, написание
+слабосвязанных компонентов в соответствии с принципами SOLID. Ведь чтобы
+тестировать компоненты приложения независимо друг от друга, нам надо,
+чтобы они были слабосвязанными. А подобное построение приложения в
+дальнейшем может положительно сказаться на его последующей модификации и
+поддержке.
+
+Большинство юнит-тестов так или иначе имеют ряд следующих признаков:
+
+**Тестирование небольших участков кода (\"юнитов\")**
+
+Для создания юнит-тестов выбираются небольшие участки кода, которые надо
+протестировать. Тестируемый участок, как правило, должен быть меньше
+класса. В большинстве случаев тестируется отдельный метод класса или
+даже часть функционала метода. Упор на небольшие участки позволяет
+довольно быстро писать простенькие тесты.
+
+Однажды написанный код нередко читают многократно, поэтому важно писать
+понятный код. Особенно это важно в юнит-тестах, где в случае неудачи при
+тестировании разработчик должен быстро прочитать исходный код и понять в
+чем проблема и как ее исправить. А использование небольших участков кода
+значительно упрощает подобную работу.
+
+**Тестирование в изоляции от остального кода**
+
+При тестировании важно изолировать тестируемый код от остальной
+программы, с которой он взаимодействует, чтобы потом четко определить
+возможность ошибок именно в этом изолированном коде. Что упрощает и
+повышает контроль над отдельными компонентами программы.
+
+**Автоматизация тестов**
+
+Создание юнит-тестов для небольших участков кода ведет к тому, что
+количество этих юнит-тестов становится очень велико. Если процесс
+получения результатов и проведения тестов не автоматизирован, то это
+может привести к непроизводительному расходу рабочего времени и снижению
+производительности. Поэтому важно, чтобы результаты юнит-тестов
+представляли собой простое решение, означающее, пройден тест или нет.
+Для автоматизации процесса разработчики обычно обращаются к фреймворкам
+юнит-тестирования
+
+**Тестирование только общедоступных конечных точек**
+
+Даже небольшие изменения в классе могут привести к неудаче многих
+юнит-тестов, поскольку реализация используемого класса изменилась.
+Поэтому при написании юнит-тестов ограничиваются только общедоступными
+конечными точками, что позволяет изолировать юнит-тесты от многих
+деталей внутренней реализации компонента. В итоге уменьшается
+вероятность, что изменения в классах могут привести к провалу
+юнит-тестов.
+
+**Фрейморки тестирования**
+
+Для написания юнит-тестов мы можем сами создавать весь необходимый
+функционал, использовать какие-то свои способы тестирования, однако, как
+правило, для этого применяются специальные фреймворки. Некоторые из них:
+
+-   xUnit.net: фреймворк тестирования для платформы .NET. Наиболее
+    популярный фреймворк для работы именно с .NET Core и ASP.NET Core
+
+-   MS Test: фреймворк юнит-тестирования от компании Microsoft, который
+    по умолчанию включен в Visual Studio и который также можно
+    использовать с .NET Core
+
+-   NUnit: портированный фреймворк с JUnit для платформы .NET
+
+Данные фреймворки предоставляют несложный API, который позволяет быстро
+написать и автоматически проверить тесты.
+
+**Разработка через тестирование (Test-Driven-Development)**
+
+Отдельно стоит сказать о концепции TDD или разработка через
+тестирование. TDD представляет процесс применения юнит-тестов, при
+котором сначала пишутся тесты, а потом уже программный код, достаточный
+для выполнения этих тестов.
+
+Использование TDD позволяет снизить количество потенциальных багов в
+приложении. Создавая тесты перед написанием кода, мы тем самым описываем
+способ поведения будущих компонентов, не связывая себя при этом с
+конкретной реализацией этих тестируемых компонентов (тем более что
+реализация на момент создания теста еще не существует). Таким образом,
+тесты помогают оформить и описать API будущих компонентов.
+
+**Порядок написания кода при TDD довольно прост:**
+
+-   Пишем юнит-тест
+
+-   Запускаем его и видим, что он завершился неудачей (программный код
+    ведь еще не написан)
+
+-   Пишем некоторое количество кода, достаточное для запуска теста
+
+-   Снова запускаем тест и видим его результаты
+
+Этот цикл повторяется снова и снова, пока не будет закончена работа над
+программным кодом. Так как большинство фреймворков юнит-тестирования
+помечают неудавшиеся тесты с красного цвета (например, выводится текст
+красного цвета), а удачный тест отмечается зеленым цветом (опять же
+выводится текст зеленого цвета), то данный цикл часто
+называют *красным/зеленым циклом*.
+
+Литература: https://metanit.com/sharp/aspnet5/22.1.ph

+ 111 - 0
Лекции/Отладка/Debugging_LVS.md

@@ -0,0 +1,111 @@
+**Отладка**
+
+Отладка, или debugging, - это поиск (локализация), анализ и устранение
+ошибок в программном обеспечении, которые были обнаружены в ходе
+тестирования.
+
+**Типы ошибок**
+
+**Ошибки компиляции**
+
+Это простые ошибки, которые обнаруживаются в скомпилированных языках
+программирования компилятором (программой, преобразующей текст на языке
+программирования в набор машинных кодов). Если компилятор показывает
+несколько ошибок, отладка кода начинается с исправления самой первой,
+поскольку она может быть причиной других.
+
+**Ошибки компоновки**
+
+Ошибки связаны с разрешением внешних ссылок. Определяет компоновщик
+(редактор ссылок) при объединении программных модулей. Простым примером
+является ситуация, когда необходимо получить доступ к подпрограмме
+другого модуля, но она не найдена во время компоновки. Ошибки также
+легко найти и исправить.
+
+**Ошибки выполнения (RUNTIME Error)**
+
+Ошибки, обнаруживаемые операционной системой, оборудованием или
+пользователями при выполнении программы. Они считаются непредсказуемыми
+и проявляются после успешной компиляции и компоновки.
+
+**Ошибки определения данных или неправильное определение исходных
+данных.**
+
+**К ним относятся:**
+
+**- Ошибки преобразования;**
+
+**- Ошибки данных;**
+
+**- Ошибки перезаписи.**
+
+**Логические ошибки**. Они могут возникать из-за ошибок, которые были
+допущены при выборе методов, разработке алгоритмов, определении
+структуры данных и кодировании модуля.
+
+В эту группу входят:
+
+**Ошибки неправильного использования переменных.** К ним относятся
+неправильный выбор типов данных, использование индексов, выходящих за
+рамки определения массивов, использование переменных перед присвоением
+переменной начального значения, нарушения соответствия типов данных;
+
+**Ошибки вычислений.** Это некорректная работа с переменными,
+некорректное преобразование типов данных в процессе расчета;
+
+**Некорректная реализация логики в программировании.**
+
+**Ошибки накопления погрешностей.** Они могут возникать при неправильном
+округлении, игнорировании ограничений битовой сетки, использовании
+приближенных методов расчета и т.д.
+
+**Методы отладки ПО**
+
+**Метод ручного тестирования**
+
+Отладка программы заключается в тестировании вручную с использованием
+набора тестов, при работе с которым была допущена ошибка. Несмотря на
+свою эффективность, метод нельзя использовать для больших программ или
+программ со сложными вычислениями. Ручное тестирование используется как
+неотъемлемая часть других методов отладки.
+
+**Метод индукции**
+
+Основой отладки системы является тщательный анализ проявлений ошибки.
+Это могут быть сообщения об ошибках или неверные результаты вычислений.
+Например, если компьютер зависает во время выполнения программы, то для
+того, чтобы найти фрагмент проявления ошибки, нужно проанализировать
+недавние действия пользователя. На этапе отладки программы строятся
+гипотезы, каждая из них проверяется. Если гипотеза подтверждается,
+информация об ошибке детализируется, если нет, выдвигаются новые.
+
+Вот как выглядит процесс:
+
+![Процесс отладки кода](./image1.png){width="2.4298611111111112in"
+height="4.250659448818897in"}
+
+Важно, чтобы выдвинутая гипотеза объясняла все проявления ошибки. Если
+объясняется только часть из них, то либо гипотеза неверна, либо ошибок
+несколько.
+
+**Метод дедукции**
+
+Сначала эксперты предполагают множество причин, по которым могла
+возникнуть ошибка. Затем они анализируют их, исключают те, которые
+противоречат имеющимся данным. Если все причины были исключены,
+проводится дополнительное тестирование. В обратном случае пытаются
+доказать наиболее вероятную причину.
+
+![отладка дедукцией](./image2.png){width="3.5347222222222223in"
+height="3.429180883639545in"}
+
+**Метод обратного отслеживания**
+
+Это эффективно для небольших программ. Все начинается с точки, где
+выводится неверный результат. Для точки выдвигается гипотеза о значениях
+основных переменных, которые могли бы привести к ошибке. Далее,
+основываясь на этой гипотезе, делаются предположения о значениях
+переменных в предыдущей точке. Процесс продолжается до тех пор, пока не
+будет обнаружена ошибка.
+
+Литература: https://blog.skillfactory.ru/glossary/otladka-debugging/

BIN
Лекции/Отладка/image1.png


BIN
Лекции/Отладка/image2.png