Загрузка данных

Отличный выбор варианта. Переход от gzip к chown требует более внимательного разбора синтаксиса, так как утилита chown имеет специфическую логику обработки аргументов (разделение на владельца/группу и целевые файлы, а также альтернативный синтаксис через флаг --reference).
Ниже представлено готовое, детально проработанное **Техническое задание (ТЗ) по ГОСТ 34.602-2020** для твоего варианта (Вариант 13), полностью адаптированное под синтаксис утилиты chown на основе её официального руководства (man chown).
# ТЕХНИЧЕСКОЕ ЗАДАНИЕ
**на разработку программного модуля проверки синтаксической корректности строки вызова утилиты chown операционной системы Linux**
## 1. Общие сведения
 * **Полное наименование системы:** Автоматизированная система проверки синтаксической корректности строки вызова утилиты chown операционной системы Linux.
 * **Условное обозначение:** chown_check.
 * **Разработчик:** студент группы [Номер группы] Мурзин М.
## 2. Цели и назначение создания автоматизированной системы
### 2.1 Цели создания АС
Целью разработки является реализация функции проверки синтаксической корректности строки вызова утилиты chown операционной системы Linux на языках программирования Pascal, C и Python, а также разработка структуры данных для накопления информации о результатах проверок и функций для управления этой структурой (обнуление, возврат, получение статистики успешных и неуспешных проверок).
### 2.2 Назначение АС
Программный модуль предназначен для:
 * Анализа и валидации текстовых строк, имитирующих вызов команды chown.
 * Хранения информации о количестве выполненных проверок.
 * Предоставления статистических данных в разрезе успешных/неуспешных проверок для интеграции в стороннее ПО на языках Pascal, C и Python.
## 3. Характеристика объекта автоматизации
### 3.1 Основные сведения (на основе man chown)
Объектом автоматизации является процесс синтаксического разбора и проверки корректности параметров строки вызова утилиты chown. Утилита chown предназначена для изменения владельца и/или группы для каждого указанного файла.
Согласно руководству man chown, синтаксис вызова утилиты разделяется на две основные формы:
 1. **Стандартная форма:** chown [ПАРАМЕТРЫ]... ВЛАДЕЛЕЦ[:[ГРУППА]] ФАЙЛ... (или :ГРУППА ФАЙЛ...)
 2. **Форма с эталоном:** chown [ПАРАМЕТРЫ]... --reference=ЭТАЛОННЫЙ_ФАЙЛ ФАЙЛ...
**Допустимые ключи и параметры (из man chown):**
 * -c, --changes — подробно докладывать о подлежащих изменению владельцах.
 * -f, --silent, --quiet — подавлять большинство сообщений об ошибках.
 * -v, --verbose — выводить диагностическое сообщение для каждого обрабатываемого файла.
 * --dereference — воздействовать на сами файлы, к которым ведут символьные ссылки (по умолчанию).
 * -h, --no-dereference — воздействовать на сами символьные ссылки вместо файлов, на которые они указывают (доступно только на системах, способных менять владельца ссылок).
 * --from=CURRENT_OWNER:CURRENT_GROUP — изменять владельца и/или группу только в том случае, если текущие владелец/группа совпадают с указанными.
 * --no-preserve-root — не обрабатывать корневой каталог / особым образом (по умолчанию).
 * --preserve-root — отклонять рекурсивную обработку корневого каталога /.
 * --reference=RFILE — использовать владельца и группу эталонного файла RFILE вместо явного указания аргумента ВЛАДЕЛЕЦ:ГРУППА.
 * -R, --recursive — рекурсивная обработка каталогов и их содержимого.
**Параметры изменения обхода дерева каталогов (используются совместно с -R):**
 * -H — если аргумент командной строки является символьной ссылкой на каталог, перейти по ней.
 * -L — переходить по всем встречающимся символьным ссылкам на каталоги.
 * -P — не переходить по символьным ссылкам (по умолчанию).
**Стандартные информационные ключи:**
 * --help — выдать справочную информацию и завершить работу.
 * --version — выдать информацию о версии и завершить работу.
> **Важное синтаксическое правило:** > Если ключ --reference **не задан**, то первый не-опциональный аргумент обязателен и должен интерпретироваться как спецификатор пользователя/группы ([OWNER][:[GROUP]]). После него должен идти как минимум один аргумент файла.
> Если ключ --reference **задан**, спецификатор пользователя/группы отсутствовать в строке команд, а все не-опциональные аргументы считаются целевыми файлами.
> 
## 4. Требования к автоматизированной системе
### 4.1 Требования к структуре и режимам функционирования
 * Система должна быть реализована в трех вариантах: автономные консольные утилиты на языках **C** и **Python** (работающие через стандартные потоки ввода-вывода stdin/stdout), и программный модуль (библиотека/юнит) на языке **Pascal**.
 * Все реализации должны функционировать в консольном режиме в среде ОС GNU/Linux x86-64.
### 4.2 Требования к функциям (функциональные требования)
Модуль должен обеспечивать выполнение следующих задач:
 1. **Ввод и первичный разбор строки:** Разбиение входной строки на токены с учетом пробелов. Поддержка комбинированных коротких ключей (например, объединение -Rvf в один токен).
 2. **Проверка имени команды:** Первым токеном строго должно являться слово chown.
 3. **Анализ ключей (опций):**
   * Проверка всех токенов, начинающихся с - или --, на соответствие списку допустимых ключей из раздела 3.1.
   * Корректное извлечение аргументов для параметров --from=... и --reference=....
   * Проверка совместимости: ключи обхода дерева (-H, -L, -P) могут быть указаны только при наличии флага рекурсии -R (или --recursive).
 4. **Валидация аргумента OWNER/GROUP (если нет --reference):**
   * Проверка структуры токена: допустимы форматы owner, owner:group, :group, owner.group.
   * Проверка соответствия имен пользователей и групп правилам POSIX (разрешенные символы: латиница, цифры, знаки подчеркивания и дефисы; имя не должно начинаться с дефиса).
 5. **Проверка целевых файлов:** Наличие как минимум одного аргумента, определяющего целевой файл или каталог, после обработки всех опций и аргумента владельца.
 6. **Управление накоплением статистики:**
   * Реализация структуры данных CheckStats со счетчиками успешных проверок (success_count) и неуспешных проверок (fail_count).
   * Функция **обнуления** структуры (reset_stats): сбрасывает счетчики в 0.
   * Функция **возврата** структуры (get_stats_struct): передает копию или указатель на текущую структуру данных.
   * Функция **получения информации** (get_stats_info): возвращает раздельные значения успешных и неуспешных проверок.
### 4.3 Требования к видам обеспечения
#### 4.3.1 Программное обеспечение
 * **Вариант на C:** Компилятор GCC версии \ge 10.3.1, стандарт C11, исполняемый файл.
 * **Вариант на Pascal:** Free Pascal Compiler (FPC) версии \ge 3.2.2, объектный модуль (.ppu/.o).
 * **Вариант на Python:** Интерпретатор CPython версии \ge 3.10, файл сценария .py.
#### 4.3.2 Техническое обеспечение
 * Процессор с архитектурой x86-64.
 * Оперативная память (RAM) от 512 МБ.
 * Свободное дисковое пространство от 100 МБ.
## 5. Состав и содержание работ по созданию системы
Разработка разбивается на следующие этапы:
 1. **Анализ требований и проектирование (2–10 мая):** Формирование ТЗ и разработка алгоритма конечного автомата (или регулярных выражений) для разбора синтаксиса chown. Создание тестового плана.
 2. **Программирование модулей (2–16 мая):** Параллельная реализация логики на C, FreePascal и Python.
 3. **Тестирование и отладка (11–16 мая):** Проведение испытаний, сбор логов тестирования.
 4. **Оформление и защита (11–16 мая):** Сборка архива 7z и подготовка к защите результатов.
## 6. Порядок контроля и приемки
Контроль качества осуществляется посредством тестирования:
 * **Реализация на Pascal:** Тестирование методом **«белого ящика»**. Разрабатывается отдельный тестовый юнит, который напрямую вызывает внутренние функции синтаксического анализа и манипулирования структурой статистики, сверяя выходы с эталонами.
 * **Реализации на C и Python:** Тестирование методом **«черного ящика»**. Осуществляется через внешнюю скриптовую систему тестирования, подающую на стандартный ввод (stdin) утилит набор тестовых строк и сверяющую код ответа и сообщения на stdout/stderr.
### Требования к тестовому плану:
План тестирования должен содержать не менее **5 категорий (типов)** тестов и не менее **25 тестовых случаев** суммарно:
 1. **Категория 1 (Позитивные тесты):** Базовые корректные команды (например: chown root file.txt, chown -R user:group /dir).
 2. **Категория 2 (Ошибки в имени и ключах):** Неверная команда (chovn ...), неизвестные ключи (chown -z file), некорректные комбинации ключей (chown -H file).
 3. **Категория 3 (Ошибки синтаксиса OWNER/GROUP):** Недопустимые символы в именах, пустые строки вместо имен при наличии двоеточия (например, chown : file.txt).
 4. **Категория 4 (Специфика флага --reference):** Проверки с правильным использованием эталона (chown --reference=ref.txt file.txt) и конфликты (одновременное указание --reference и явного user:group).
 5. **Категория 5 (Проверка функций статистики):** Тесты на последовательный вызов функций валидации с контролем инкремента счетчиков, проверкой сброса (reset) и корректности возврата структуры.
## 7. Порядок подготовки объекта к вводу в действие
Инструкции по развертыванию сред для проверки:
 * **Для Pascal:** Наличие установленного пакета fpc. Компиляция проверочной программы: fpc test_chown.pas.
 * **Для C:** Наличие установленного пакета gcc. Компиляция: gcc -O2 chown_check.c -o chown_check.
 * **Для Python:** Наличие интерпретатора python3. Запуск проверки прав на исполнение: chmod +x chown_check.py.
## 8. Источники разработки
 1. ГОСТ 34.602—2020 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы».
 2. Справочное руководство Linux: man chown (пакет coreutils).
 3. Документация к компиляторам GCC, Free Pascal и интерпретатору CPython.