Готовя текст, автор сталкивается с особенными типами речи — функционально-смысловыми. Тот или иной функционально-смысловой тип речи, подчиняясь этосу и пафосу, становится частью логоса.
Функционально-смысловые типы речи — такие типы монологической речи, которым свойственны свои цели и задачи, однотипность содержания, композиции и речевых особенностей. Выделяют следующие типы речи — описание, повествование, рассуждение
Описание как тип речи — определение, предмет и цельОписание — это тип речи, в котором перечисляются постоянные или временные признаки предмета.
Предмет описания определен изначально и раскрывается через перечисление признаков, постоянных и временных.
Описание статично, действие не развивается, при этом описание может быть дано как в настоящем (что чаще всего и встречается, употребляются глаголы в форме настоящего времени, несовершенного вида), так и в прошедшем и будущем времени (время в этом случае приобретает относительный, обобщенный характер).
В описании невозможно сочетание времен глагола.
Цель описания — дать адресату наиболее полное представление о предмете.
При объективном описании автор приводит бесспорные признаки описываемого предмета или явления, не высказывая своего отношения, при субъективном описании автор отбирает факты, средствами языка подчеркивает свое отношение к ним.
Ведущая часть речи в этом типе — имя существительное, имя прилагательное.
Для описания характерно использование простых предложений,часто с однородными членами предложения.
Принцип построения — параллелизм (однотипность конструкций), интонация — перечисления.
Композиция описания
1. Зачин — обозначение объекта (предмета описания), общее представление о предмете;
П. Основная часть — перечисление признаков от более существенных к менее существенным;
Ш. Концовка — авторское отношение к предмету, вывод, заключение.
Описывая предмет, необходимо обеспечить единство изображения, единство взгляда на предмет и логическую последовательность при его описании.
Определение
Это самый краткий вид описания. Оно заключается в соотнесении понятия с ближайшим родовым понятием (Антонимы — это слова…) и указании на видовые отличия данного понятия или явления (Антонимы — это слова с противоположным значением).
При определении понятия можно использовать сравнение, контраст, пример-иллюстрацию
(Российская экономика — это экономика периода перехода с правостороннего движения на левостороннее. — определение-сравнение; Поэзия — это нечто противоположное прозе. — определение- контраст; «Синий апельсин» — это и есть лексическая несочетаемость — определение- пример).
Объяснение
Это своеобразная трансформация определения и отличается развернутой формой подачи материала.Например,
Соотношение языка и речи можно уподобить соотношению деталей часов и собранным часам. Язык дает материал для строения речи. Так же, как от часовщика зависит, какими будут часы, так и от говорящего зависит, какой будет его речь.
Характеристика
Еще одна разновидность описания. При составлении характеристики необходимо указать только на существенные признаки данного предмета или явления, тогда как при развернутом описании указываются как существенные, так и несущественные признаки (в зависимости от цели автора).
Наша презентация:
Характерным недостатком при составлении текста-описания может быть отбор признаков или их неправильный порядок при изложении.
Вам понравилось? Не скрывайте свою радость, поделитесь ею с миром!Материалы публикуются с личного разрешения автора — к.ф.н. О.А.Мазневой (см. «Наша библиотека»)
Запись опубликована в рубрике Русский язык. Добавьте в закладки постоянную ссылку.
4.1
Средняя оценка: 4.1
Всего получено оценок: 577.
4.1
Средняя оценка: 4.1
Всего получено оценок: 577.
Каждый тип речи в русском языке уникален и имеет собственные признаки и характерные черты.
Умение отличать дин тип речи от другого очень важно: это значительно облегчает работу с текстами и помогает и самому выразить мысль правильно.
Этот принцип широко применяется для более простого и наглядного объяснения того, к какому именно типу относится художественный текст. Так, если речь идет о повествовании, то к тексту в целом можно задать два вопроса: Что произошло? и Как произошло? А если применить к нему прием фотографирования, то можно сказать, что “снять” то, что описывается в нем, можно с нескольких ракурсов.
Такой тип текста, как рассуждение, отвечает на общий вопрос “почему?”, а вот снимков с него сделать нельзя.
Наконец, описание – это когда текст отвечает на вопрос “какой?”, а снимок описываемого сделать можно, но только один.
Такой прием, как фотографирование, действительно является самым простым и при этом наглядным способом определения типа текста, так как он позволяет представить все с точки зрения активного наблюдателя, которому надо сделать снимок.
Так, в описании тема текста раскрывается с помощью характеристик предметов, событий и так далее. Это похоже на перечисление признаков описываемого. Поскольку все происходит в момент речи, то можно говорить о том, что у данного типа речи есть две характерные черты – определенность и статичность. Примерами описаний можно назвать рассказ о человеке, пейзаж и так далее.
Повествование – то самое, которое можно снять с разных ракурсов – показывает тему в развитии, то есть его характерная черта – динамичность, подчеркивается она использованием глаголов в большом количестве. Изобилуют там и наречия, с помощью которых автор указывает на последовательность происходящего. Самым простым примером повествования является рассказ о том, как школьник провел лето и тому подобное.
Повествование и описание являются антонимичными типами текстов, поскольку для первого характерна динамичность, а для второго статичность, а это значит, что противопоставляются их основные признаки.
Что касается рассуждения, то в этом типе текста все основывается на умозаключениях. Он имеет логическое начало (оно же – главный тезис), основную часть (аргументацию, подтверждающую или даже опровергающую этот тезис) и, конечно же, вывод.
Для русского языка характерны три типа речи, два из которых – повествование и описание – противопоставляются друг другу по признакам динамичности и статичности соответственно. Третий тип, рассуждение, стоит отдельно. Каждый из них имеет характерные черты, позволяющие отличить их один от другого. Самым простым способом для этого является принцип фотографирования, основанный на мысленной визуализации текста. В зависимости от того, можно его “сфотографировать” или нет, и отличаются разные типы текста – таков общий принцип.
Доска почёта
Чтобы попасть сюда – пройдите тест.
Динара Широкова
5/5
Наталья Шатрова
5/5
Angenehm Mann
5/5
Наталия Семушкина
5/5
Илья Курочкин
3/5
Вова Шаховский
5/5
Ксения Вересова
4/5
Елена Гришина
5/5
Димитрий Якушов
5/5
4.
Средняя оценка: 4.1
Всего получено оценок: 577.
А какая ваша оценка?
Задача состояла в том, чтобы предоставить рекомендации для хороших контекстных описаний. Контекстные описания во многих книгах и онлайн-статьях похожи на пользовательские истории. Однако описания, похожие на истории, становятся сложными для функций, которые развиваются с течением времени. Подробное объяснение проблемы см. в исходном сообщении. Эта статья содержит анализ ответов сообщества и советы по более общим подходам к решению подобных проблем.
Фейт Петерсон написала два отличных ответа на этот вызов. В первом рассматривается более общий вопрос о решении правильной проблемы, определяя, как «попытка написать что-то расплывчатое часто является признаком того, что с моим анализом что-то пошло не так». Она предостерегает от описания решений до понимания реальной проблемы. Хотя это и не имеет прямого отношения к задаче, я настоятельно рекомендую прочитать эту статью.
Описание контекста, и это в равной степени относится к функциям и сценариям, предназначено для предоставления дополнительной информации, которая слишком длинна для того, чтобы содержать ее в заголовке, но было бы нецелесообразно показывать ее в отдельных примерах. В идеале текст контекстного описания должен помочь читателям и специалистам по сопровождению легче понять примеры и принять правильное решение об обновлении данных в будущем.
Поскольку контекстные описания не автоматизированы, они не должны следовать жесткой структуре. Вам не нужно заставлять себя вписывать его в какой-то конкретный формат. Итак, отвечая на вопрос из заголовка, связанный с пользовательскими историями: может, но не должен, а часто и не должен.
Вступительное заявление файла функций должно говорить о назначении этой функции.
Объясните, зачем все это нужно, чтобы читатели могли знать, просматривают ли они нужный файл или нет. Это также очень помогает подготовить почву для сценариев.
Если пользовательская история подходит для этой цели, обязательно используйте ее. Очень часто при добавлении новой функции или сценария первоначальная история является хорошим способом передать цель. По мере роста функциональности переписывайте контекст, уточняйте его и отбрасывайте части, которые не имеют смысла. Некоторые люди продолжают добавлять несколько описаний историй к описанию функции, но это очень быстро становится слишком длинным и слишком скучным.
Фейт предложил реструктурировать файлы функций по мере развития функциональности. Один из вариантов в ее посте — разделить файл функций на папку с файлами, каждый из которых имеет очень конкретную цель. Это хороший способ работы с функцией, которая развивается по-разному, и различные аспекты функциональности представляют ценность для разных людей. Если одна и та же часть функциональности служит нескольким целям, то лучше перефразировать или реструктурировать истории во что-то другое.
При работе с функцией, которая была разработана для удовлетворения потребностей нескольких пользователей, иногда люди пытаются перефразировать категорию пользователя в более общую. Фейт приводит пример «потребителей отчетов» или «читателей отчетов», которые могут подразумевать все различные типы сотрудников, имеющих доступ к отчету о счетах, и показывает, насколько это слишком широко, чтобы помочь понять.
Я предпочитаю перечислять все связанные роли, но, возможно, по-другому. Обычно вы можете выбросить часть пользовательских историй «Я хочу», потому что это будет подразумеваться сценариями в файле.
Функция: отчеты по учетным записям
Отчеты по учетным записям в основном используются менеджерами по работе с клиентами.
контролировать кредитный риск клиента. Они также используют эти отчеты
принять решение о праве на скидки и специальные предложения.
Среди других пользователей:
* операторы колл-центра, которые используют их для быстрого поиска
при недавних транзакциях, чтобы помочь клиентам, когда они по вызову
* бухгалтеры для проверки налоговых отчетов на конец года
Сценарий: … Фейт предлагает написать «рассказ» вместо истории и дает отличный пример определения личности, потребности и предлагаемого решения в гораздо более длинном формате.
Функция: ожидающий отчет о счете Сабина, менеджер по работе с клиентами, отвечает за поддержку Acme.Подверженность финансового сектора кредитному риску в пределах определенных уровней. В одну сторону она делает это, чтобы внимательно следить за тем, есть ли клиенты, у которых есть истории медленной оплаты оплатили свои текущие счета или если эти счета рискуют стать просроченными. Когда она делает это, она хочет видеть список всех клиентов с выставлением счетов даты в течение следующих трех рабочих дней со счетами, которые в ожидании. (Ожидание означает, что счет был выставлен и оплата либо не получено, либо не оплачено.)
Для очень сложных функций вы также можете использовать этот вид введения для отдельных сценариев или схем сценариев. Например, если в отчеты добавлены некоторые специальные функции для операторов колл-центра, чтобы быстро помочь клиентам, укажите их только во введении к связанным сценариям.
Для описаний сценариев документирование цели часто означает объяснение основного бизнес-правила.
Иногда одного сценария недостаточно для демонстрации бизнес-правила, поэтому полезно предоставить более общее описание правила для целой группы сценариев. Описание файла функций — хорошее место для этого. Вера приводит хороший пример в своем посте:
Подверженность финансового сектора кредитному риску в пределах определенных уровней. В одну сторону
она делает это, чтобы внимательно следить за тем, есть ли клиенты, у которых есть
истории медленной оплаты оплатили свои текущие счета или если
эти счета рискуют стать просроченными. Когда она делает
это, она хочет видеть список всех клиентов с выставлением счетов
даты в течение следующих трех рабочих дней со счетами, которые
в ожидании. (Ожидание означает, что счет был выставлен и оплата
либо не получено, либо не оплачено.) Функция: Отчет об ожидающих счетах
Правило: менеджеры по работе с клиентами могут видеть только ожидающие счета
для назначенных им клиентов
Правило: Супервайзеры по управлению аккаунтом могут видеть ожидающие счета
для клиентов, назначенных менеджерам по работе с клиентами, за которыми они наблюдают Обратите внимание, что Gherkin (независимый от инструментов язык для файлов функций «Дано-когда-тогда») ввел специальное ключевое слово для группировки сценариев – Правило. Однако не все инструменты поддерживают это, но Specflow поддерживает. Ключевое слово Rule позволяет указать некоторый контекст, применимый к набору сценариев, но не обязательно ко всему файлу функций.
Вы можете использовать контекстные описания, чтобы лучше управлять ожиданиями заинтересованных сторон или коллег, не входящих в непосредственную команду.
Хорошее название должно объяснять общий масштаб бизнеса, но оно не может документировать решения по объему проектирования. Просто не хватает места. Если вы отложили какую-то функциональность, чтобы быстрее выпустить первоначальную версию, или договорились, что что-то полностью выходит за рамки, укажите это во вступлении к файлу, чтобы потом вас не беспокоили. Объясните сомнительные аспекты того, что входит в сферу охвата, что выходит за рамки и почему. Например:
Функция: отчеты по учетным записям … Эта функция явно исключает транзакции из устаревшего базу данных, которая будет добавлена в следующей итерации (Christian одобрил это по электронной почте 13 января).
Этот трюк одинаково хорошо применим к сценариям и схемам сценариев. Если вы решили исключить класс примеров из сценария, теоретически вы могли бы настроить примеры, показывающие, как система их отклоняет, но это может оказаться излишним. Иногда достаточно просто объяснить, почему они были исключены.
Например:
Схема сценария: фильтрация по валюте Европейские валюты, кроме евро, не указаны ниже, поскольку в настоящее время невозможно настроить учетную запись ЕС с другую валюту через пользовательский портал. Нам может понадобиться вернитесь к этому после обновления пользовательского портала. …
Если примеры не говорят сами за себя, обязательно задокументируйте структуру. Объясните, почему в сценариях перечислены важные части данных и почему некоторые другие не менее важные поля отсутствуют. Четко задокументированная структура примеров помогает сосредоточить внимание читателей и привести всех в соответствие с терминологией и моделью.
Функция: отчеты по учетным записям … Для оценки риска мы используем только Консолидированную чистую сумму, которая представляет собой стоимость после уплаты налогов, преобразованную в первичную стоимость продавца. валюта. В отчетах не учитываются расходы на доставку и налоги.
Вера идет еще дальше и предлагает явно указывать определения важных терминов в описании:
Это
не имеет значения для оценки риска, но может варьироваться в зависимости от страны, поэтому
их включение может привести к сложным расчетам и вводящим в заблуждение
Результаты. Функция: Отчет об ожидающих счетах
Менеджер по работе с клиентами: человек, который управляет отношениями Acme с
определенный набор клиентов
Ожидающий счет: счет, который был выставлен, но еще не оплачен Для простых файлов функций, где все сценарии используют одинаковую структуру, это можно сделать в заголовке функции. Для более сложных файлов функций, возможно, стоит сделать это в описаниях отдельных сценариев.
Обычный способ испортить сценарий или описание функции — обобщить данные из примеров. Это особенно важно помнить, если вы хотите задокументировать бизнес-правило в описании.
Когда сценарий или контекст функции повторяют данные из примеров, то это не добавляет информации в исполняемую часть спецификации, а просто усложняет ее.
Это распространенный симптом проблемы, которая вызывает длительные головные боли при обслуживании. Вот пример:
Сценарий: рискованные счета должны отображаться отдельно Должны быть показаны все клиентские счета с общим фактором риска > 0,5. на вкладке "Рискованные" Учитывая следующие учетные записи пользователей | идентификатор аккаунта | фактор риска | | низкий-1 | 0,10 | | низкий-2 | 0,49 | | предел-3 | 0,50 | | выше предела-4 | 0,51 | | высокий риск-5 | 0,99 | Когда создается отчет об учетной записи клиента Затем в категории «Рискованные» должны появиться следующие счета. | идентификатор аккаунта | фактор риска | | предел-3 | 0,50 | | выше предела-4 | 0,51 | | высокий риск-5 | 0,99 |
Проблема с этим контекстом сценария заключается в том, что он снова дает нам ту же информацию в другом формате. Он не предоставляет никакой дополнительной информации для понимания цели или структуры. Хуже того, поскольку контекстное описание не привязано к исполняемому шагу, нелегко поддерживать актуальность остальной системы.
Если кто-то решит изменить лимит в будущем, он может обновить примеры, но забудет обновить контекст. Это частая причина путаницы при поддержке файлов функций.
Было бы гораздо лучше сделать контекст более общим и объяснить цель, чтобы в будущем люди могли лучше решать, как редактировать примеры. Вдобавок, делая контекст более общим, часто вынуждает людей немного больше думать о модели. Что на самом деле представляет собой это магическое значение 0,5? Это еще одна ситуация, когда помогает метод дать ему хорошее доменное имя . Определение хорошего имени, такого как «порог риска учетной записи», дает понять, что это свойство модели, и позволяет нам спроектировать систему так, чтобы ее было легче изменить в будущем. Вот один из возможных способов переписать этот сценарий:
Сценарий: рискованные счета должны отображаться отдельно Менеджерам по работе с клиентами нужен быстрый способ определения учетные записи, которые не должны быть разрешены для получения скидок, долго Условия оплаты или большой кредит.
Если порог риска изменится в будущем, нам не нужно обновлять или изменять какие-либо функции или тесты. Идентифицируя его как свойство домена, мы можем сделать систему настраиваемой.
Кроме того, если необходимо изменить базовую логику, легко определить функции, которые включают порог риска, и обсудить, как их следует обновить. Контекст сценария поможет нам решить, как его разделить и переписать. Типичное утверждение «Как… для того, чтобы… я хочу…» не подходило бы даже близко к этому.
Конечно, в описание функции можно добавить еще много вещей. Один из лучших способов описать контекст функции или сценария — проверить, какой информации более высокого уровня не хватает в примерах. В конце концов, текст в свободной форме дополняет исполняемые примеры и облегчает их понимание. Покажите файл функций или сценарий тому, кто не участвовал в семинаре по спецификации (сессия открытия или сеанс совместного анализа). Найдите кого-нибудь, кто разбирается в предметной области, но не участвовал в дискуссиях. Просто покажите им файл функций, спросите, понимают ли они его, и молчите. Посмотрите, какие вопросы они задают, и постарайтесь ответить на них в контекстном описании.
Очень вероятно, что у кого-то, кто будет читать тот же файл в будущем, могут возникнуть похожие вопросы, и наличие готовых ответов будет означать, что им не придется преследовать вас по этому поводу.
Вы можете проверить, правильно ли вы это сделали, показав это еще одному человеку, и посмотреть, не упущено ли что-то еще.
В качестве дополнительного совета: некоторые инструменты документирования могут применять расширенное форматирование к сценариям и описаниям функций. Например, Specflow позволяет использовать Markdown для добавления ссылок, встраивания изображений и лучшего форматирования текста. При просмотре файла функций с помощью LivingDoc синтаксис уценки становится HTML, что позволяет вам предоставлять гораздо больше, чем просто текст, с вашей живой документацией. Вы можете добавить веб-ссылки на связанные функции или диаграммы, которые лучше объясняют область действия функции.
Описание используется во всех формах письмо, чтобы создать яркое впечатление о человеке, месте, объекте или событии, например:
Описательное письмо обычно используется, чтобы помочь писателю развить аспект своей работы, например.
для создания особого настроения, атмосферы или описания места, чтобы читатель мог создать живые образы персонажей, мест, предметов и т. д.
Описательное письмо будет следовать стилю и процессу конкретного письма (например, повествование, отчет, рецепт, пересчет), поэтому основное внимание при планировании будет уделяться развитию богатого словарного запаса, который создаст яркие образы для читателя. .
Вот некоторые процессы, которые могут быть полезны при составлении этого сценария для писателя:
В настоящее время у нас нет конкретных факторов риска для этих трех
категории, но используйте общий фактор риска на счете (это
в будущем может измениться).
На вкладке «Рискованные» отчетов об учетных записях должны быть перечислены все учетные записи.
когда общий риск превышает порог риска счета, но
только эти аккаунты.
Учитывая порог риска 0,5
И следующие учетные записи пользователей
| идентификатор аккаунта | фактор риска |
| низкий-1 | 0,10 |
| низкий-2 | 0,49|
| предел-3 | 0,50 |
| выше предела-4 | 0,51 |
| высокий риск-5 | 0,99 |
Когда создается отчет об учетной записи клиента
Затем в категории «Рискованные» должны появиться следующие счета.
| идентификатор аккаунта | фактор риска |
| предел-3 | 0,50 |
| выше предела-4 | 0,51 |
| высокий риск-5 | 0,99 |