12
СОПОСТАВИТЕЛЬНЫЕ ИССЛЕДОВАНИЯ И ПЕРЕВОД / COMPARATIVE AND TRANSLATION STUDIES
УДК 81'33 ББК 81.1
DOI: https://doi.Org/10.17308/lic.2021.2/3414
СПОСОБЫ ВЫРАЖЕНИЯ МОДАЛЬНОСТИ В ПАРАЛЛЕЛЬНЫХ ТЕКСТАХ СТАНДАРТОВ (НА ПРИМЕРЕ НОРМАТИВНОЙ БАЗЫ ПРОГРАММНОЙ ИНЖЕНЕРИИ)
Ю. И. Бутенко, Н. А. Авагян
Московский государственный технический университет имени Н. Э. Баумана
WAYS OF EXPRESSING MODALITY IN PARALLEL STANDARDS TEXTS (ON NORMATIVE FRAMEWORK OF SOFTWARE ENGINEERING)
Yu. I. Butenko, N. A. Avagyan Bauman Moscow State Technical University
Аннотация: статья посвящена исследованию способов выражения модальности в текстах стандартов нормативной базы программной инженерии на английском и русском языках. Подчеркнуто, что отличительной чертой текстов стандартов является широкое использование модальных глаголов, обусловленной функциональными особенностями текстов нормативной базы. Рассмотрены случаи использования модальных глаголов в английском языке и способы их передачи средствами русского языка в параллельных текстах стандартов. Представлены статистические данные по частотности употребления английских модальных глаголов в текстах стандартов программной инженерии. Проведен количественный анализ соответствия средств выражения модальности в текстах стандартов на английском языке средствами русского языка. Построена схема соответствия модальных глаголов английского языка средствам выражения модальности в русском языке на примере текстов стандартов нормативной базы программной инженерии. Установлено наличие несоответствия способов выражения модальности английского языка средствами русского языка. Отмечено, что некорректный перевод модальных глаголов с английского языка на русский в текстах стандартов нормативной базы программной инженерии может привести к неточностям при разработке нормативных профилей в процессе создания и сертификации программного обеспечения.
Ключевые слова: тексты стандартов, модальность, модальные глаголы, лексические особенности, анализ текстов, степень долженствования.
Abstract: article is devoted to research of ways of expression of a modality in texts of standards of normative base of software engineering in English and Russian languages. It is underlined, that distinctive feature of texts of standards is the wide use of modal verbs caused by functional features of texts of normative base. Cases of use of modal verbs of English and ways of their transfer by means of Russian language in parallel texts of standards are considered. The statistical data on frequency of use of English modal verbs in the texts of standards of software engineering are presented. The quantitative analysis of correspondence of the means of modality expression in the texts of standards in English by the Russian language means has been carried out. The scheme of correspondence of English mole verbs to the means of modality expression in the Russian language was constructed on the example of the texts of standards of normative base of software engineering. It is established that there is a discrepancy between the methods of English modality expression by the Russian language means. It is noted that incorrect
© Бутенко Ю. И., Авагян Н. А., 2021
®
Контент доступен под лицензией Creative Commons Attribution 4.0 License. The content is available under Creative Commons Attribution 4.0 License.
translation ofmodal verbs from English into Russian in the texts of the standards of the normative base of software engineering can lead to inaccuracies in the development ofnormative profiles in the development and certification of software.
Key words: standards texts, modality, modal verbs, lexical features, text analysis, degree of obligation.
Введение
Стандартом принято называть нормативный документ, разработанный на основе консенсуса, утвержденный признанным органом, направленный на достижение оптимальной степени упорядочения в определенной области [1]. В стандартах указывают все виды и нормы допустимой опасности касательно конкретного продукта или группы однородной продукции. Они разработаны с расчетом на безопасность объекта стандартизации в течение всего периода его использования.
В настоящее время при подготовке технического задания, разработке или сертификации программного обеспечения специалистам приходится не только изучать требования русскоязычных нормативных документов, но и в случае с работой с международными стандартами обращаться к их англоязычной версии. Нормативная база программной инженерии представлена документами разных международных организаций, таких как ИСО, МЭК, МАГАТЭ, которые издают свои стандарты на английском языке. Такие действия специалисты объясняют необходимостью удостове -риться в корректности перевода, если в последующем планируется выпуск программного продукта на иностранные рынки, так как при сертификации продукции за рубежом будут руководствоваться требованиями из англоязычных нормативных документов.
Требования стандартов содержат критерии, которые должны быть соблюдены. Стандарты могут содержать обязательные требования, подлежащие обязательному выполнению в соответствии с законом или действующим регламентом, и альтернативные требования и положения [1]. В текстах стандартов обязательные и альтернативные требования выражены посредством использования модальных глаголов. Зачастую одно требование выражено одним предложением, а используемый модальный глагол указывает на вид требования - обязательное или альтернативное.
В настоящее время можно найти большое количество работ по модальности. Однако, несмотря на наличие большого интереса исследователей к данной теме, модальность в научно-технических текстах мало изучена. Наличие разных точек зрения на понятие «модальность», вопросов с выделением видов и
средств модальности, вопросов о способах проявления модальности в научно-технических текстах ставят перед исследователями ряд задач по ее дальнейшему исследованию.
Целью данной работы является исследование способов выражения модальности в англоязычных и русскоязычных параллельных текстах стандартов нормативной базы программной инженерии.
Способы выражения модальности в параллельных текстах стандартов
Материалом исследования послужили 1500 примеров использования модальных глаголов в текстах стандартов программной инженерии на английском языке и их перевод на русский. В ходе исследования был использован статистический метод для определения количественных характеристик способов выражения модальности в текстах стандартов, а также сравнительный метод для исследования способов выражения модальности в текстах нормативной базы программной инженерии.
Тексты стандартов обладают рядом лингвистических особенностей, наиболее яркими среди которых являются синтаксические характеристики предложения с позиции выявления их семантики и степени долженствования, выраженной модальными глаголами [2; 3]. В текстах нормативной базы можно выделить глаголы, выражающие утвердительную модальность, обязательность соблюдения требования, и гипотетическую модальность, возможность, вероятность, факультативность соблюдения требования [4].
Для выражения обязательности соблюдения требования в англоязычных текстах стандартов программной инженерии используют модальные глаголы must, have to, to be to.
Самым категоричным модальным глаголом, используемым в текстах стандартов, является must. Он выражает необходимость однозначного и неуклонного соблюдения требования, содержащегося в тексте стандарта [5]. В исследуемом иллюстративном материале модальный глагол must использовался 62 раза. На русский язык must в текстах нормативной базы программной инженерии переводится как «должен» и «необходимо», например:
When applying this standard in conjunction with В случае если настоящий стандарт применяется в соче-ISO/IEC15288, one minor mismatch in terminology тании с ISO/IEC 15288, то должно учитываться любое must be considered. незначительное несоответствие в терминологии.
The organization shall identify any multi-project interfaces that must be managed or supported by the project.
For example, in a case of banking cash dispenser, turn around time is a time from pressing initial key until you get money, meanwhile you must select type of transaction and wait for a message, input password and wait for the next message etc.
Организация должна определять любые взаимосвязи между многими проектами, которые должны управляться или поддерживаться данным проектом.
Во многих случаях оборотное время включает много ответных действий. Например, в случае банкомата оборотное время - это время от нажатия первой кнопки и до момента получения денег, между тем необходимо выбрать тип транзакции и ждать сообщения, ввести пароль и ждать следующего сообщения и т. д.
Модальный глагол «must» в текстах стандартов программой инженерии переводится на русский язык как «должен» в 80 % случаев. Данный перевод соответствует своему исходному значению. Также модальный глагол «must» приобретает значение «необходимо» в 20 % случаев.
Другим модальным глаголом, выражающим необходимость обязательного соблюдения требования, является have to, при этом может выражать необходимость совершения действия в связи с обстоятельствами, оговоренными в требовании. В исследуемых текстах стандартов выявлен 61 случай употребления модального глагола have to, например:
Technical Reports of type 3 do not have to be reviewed until the data they provide are considered to be no longer valid or useful. When a user has to apply an adaptation procedure other than previously provided by software for a specific adaptation need, user's effort required for adapting should be measured.
Step 1 has to be completed during the Requirement Analysis activity. Steps 2 to 5 have to be repeated during each process activity defined above.
Технические Отчеты 3 типа не обязательно подвергать рассмотрению до тех пор, пока предоставляемые ими данные перестанут считаться обоснованными или полезными. Следует измерить усилие пользователя, необходимое для приспособления «под себя», если пользователь вынужден применить процедуру адаптации, отличную от предварительно предоставленной программным обеспечением, для определенного требования к адаптации. Шаг 1 должен быть закончен в течение действия по Анализу Требований. Шаги 2-5 должны быть повторены в течение каждого действия, определенного выше.
Модальный глагол «have to» при переводе на русский язык переводится как «вынужден» (20 %), «должен» (60 %). В 20 % случаев глагол используется с отрицательной частицей not в виде конструкции do not have to, что обозначает отсутствие необходимости выполнять действие и переводится на русский язык как «необязательно».
Еще одним модальным глаголом, указывающим на необходимость соблюдения требования, является глагол ^ Ье ?о. Модальный глагол ^ Ье ^ выражает необходимость, распоряжение, неизбежность, возможность, непременное условие [6; 7]. Проанализированы 59 примеров употребления модального глагола « ^ Ье ?о» в текстах стандартов нормативной базы программной инженерии, например:
The following table clarifies how an ISMS family of standards document is to be interpreted in terms of its verbal expressions as being either requirements or recommendations.
The tasks of the Software Maintenance Process, that are required when documentation is to be modified, shall be performed (see subclause 6.4.10). Which metrics are to be applied will depend on the relative importance of different aspects of usability, and the extent of subsequent quality in use testing.
When applied internally, the contractual language is to be interpreted as self-imposed discipline.
Нижеприведенная таблица дает пояснения, каким образом должны интерпретироваться стандарты семейства СМИБ в части глагольных формулировок, которые либо устанавливают требования, либо служат рекомендациями.
Должны выполняться задачи процесса сопровождения программных средств, которые необходимы при изменениях в документации (см. 6.4.10). Какая из метрик будет применяться, зависит от относительной значимости различных аспектов практичности и от степени дальнейших испытаний на качество в использовании.
Если стандарт применяется для внутренних целей, то положения контракта следует интерпретировать как установленную в пределах организации исполнительскую дисциплину.
В исследуемых текстах стандартов было выявлено, что при переводе с английского языка на русский язык модальный глагол to be to (not) переводится как «(не) должен» (40 %), «необходимо» (20 %), «следует» (20 %). При этом выявлено, что в 20 % случаев модальное значение глагола to be to не передано в русскоязычной версии текста стандарта.
Модальный глагол «should» чаще всего передает значение рекомендации, совета и упрека, а также может придавать всему высказыванию ярко выра-
Comments on the content of this document should be sent to the ISO Central Secretariat. If the software operates discontinuously, it should be assured that the time measurement is done on the periods the software is active (this is obviously extended to continuous operation). The programming language should be explained and it should be provided how the non executable statements, such as comment lines, are treated. The user of these Technical Reports should select the quality characteristics and sub-characteristics to be evaluated, from ISO/IEC 9126-1; identify the appropriate direct and indirect measures, identify the relevant metrics and then interpret the measurement result in an objective manner.
A sample of users who are representative of an identified user group should carry out the test without any hints or external assistance.
Under one contract or application of this standard, a given party should not perform both the Acquisition Process and the Supply Process, but it can perform other processes.
В результате анализа текстов стандартов выявлено, что модальный глагол «should (not)» при переводе на русский язык получает такие значения, как «(не) следует» (50 %), «надо» - (10 %). Модальный глагол «should (not)» приобретает такие значения, как «(не) должен» (20 %), «необходимо» (10 %), «можно» (9 %). В самих исследуемых тестах стандартов указано, что данный модальный глагол переводится на русский язык как «следует». Выявлено, что модальный глагол «should» может не переводиться на русский язык (1 %).
Echoes compared shall be obtained from the same reflector.
ISO and IEC shall not be held responsible for identifying any or all such patent rights.
женную эмоциональную окраску [8]. В текстах стандартов модальный глагол «should» относится к глаголам долженствования и рекомендации выполнить требование, в тексте которого встречается этот глагол. Проанализированы 242 примера употребления модального глагола «should» в текстах стандартов на примере нормативной базы программной инженерии. Многообразие переводных эквивалентов данного модального глагола может поставить в неоднозначное положение тех, кто работает со стандартом, например:
Наиболее часто используемым модальным глаголом в текстах стандартов является shall, который в качестве модального глагола употребляется со 2-м и 3-м лицом единственного и множественного числа в утвердительных и отрицательных предложениях для выражения необходимости, обязательства, приказания [9]. В рамках исследования были проанализированы 516 примеров употребления модального глагола «shall» в текстах стандартов нормативной базы программной инженерии, например:
Cравниваемые эхо-сигналы должны быть от одного и того же отражателя.
ISO и IEC не несут ответственности за определение любого из таких патентных прав.
Комментарии по содержанию данного документа следует присылать в Центральный Секретариат ISO. Если программное обеспечение работает с перерывами, то надо удостовериться, что измерение времени сделано тогда, когда программное обеспечение активно (т. е. работает непрерывно).
Язык программирования необходимо объяснять, что можно обеспечить путем вставки неисполняемых операторов, например, строк комментариев. Пользователь данных Технических Отчетов должен выбрать из ISO/IEC 9126-1 характеристики и подха-рактеристики качества, которые необходимо оценить; установить соответствующие прямые и косвенные показатели (единицы измерений); установить метрики соответствия (relevantmetrics), а затем объективно интерпретировать результат измерений. Проверка проводится выборкой пользователей, являющихся представителями определенной группы пользователей, в отсутствие любого рода советов и исключая любую внешнюю помощь.
Например, по условиям контракта или применения настоящего стандарта конкретная сторона не должна выполнять ни процесс приобретения, ни процесс поставки, но она может выполнять другие процессы.
The terms "shall" and "shallnot" indicate requirements strictly to be followed in order to conform to the document and from which no deviation is permitted.
The project shall evaluate the balance of consequences of alternative actions, using the defined decision-making strategy, to arrive at an optimization of, or an improvement in, an identified decision situation.
Stage 3 of the flowchart procedure shall be applied only to those indications exceeding:
Модальный глагол «shall (not)» в текстах стандартов программной инженерии переводится на русский язык, как «(не) должен» - одно из основных значений данного модального глагола (85 %). Также модальный глагол «shall» при переводе на русский язык придает тексту намерение или твердое обещание - (0,2 %). Модальный глагол «shall» также переводится как «следует» (14 %), «необходимо» (5 %), что нарушает структурность текста, исходное значение данного модального глагола.
Слова «должен» («shall») и «не должен» («shall not») означают требования, которым необходимо строго следовать для того, чтобы соответствовать документу, и никакие отклонения не допустимы.
При реализации проекта необходимо оценивать баланс последствий альтернативных действий, используя определенную стратегию принятия решений с целью оптимизации или улучшения ситуации принятия решений.
Этап 3 процедуры следует применять только к тем дефектам, протяженность которых превышает:
В текстах нормативной базы программной инженерии переводными эквивалентами модального глагола will/would чаще всего являются глаголы, передающие возможность или предложение выполнить требование документа [10]. Проанализированы 67 примеров модального глагола «will/would» в текстах стандартов на примере нормативной базы программной инженерии, например:
NOTE It is possible, that some of the rows of the tables would be empty during the specific activities of the development cycle, because it would not be possible to measure all of the subcharacteristics early in the development process.
The choice of functions to test will be influenced by the expected frequency of use of functions, the criticality of the functions, and any anticipated usability problems.
This ISMS review will check that the ISMS includes specified controls that are suitable to treat risks within the ISMS scope.
Avoiding risks by not allowing actions that would cause the risks to occur.
Furthermore, based on the records of these monitored areas, it will provide evidence of verification, and traceability of corrective, preventive and improvement actions.
Organizational models for project use would be provided through the Life Cycle Model Management Process.
Record, categorize and promptly and objectively report problems or opportunities and the alternative courses of action that will resolve their outcome.
ПРИМЕЧАНИЕ. Возможно, что некоторые из рядов таблиц будут пусты в течение определенных действий цикла разработки, потому что невозможно измерить все подхарактеристики в процессе разработки.
Выбор функций для испытаний будет зависеть от ожидаемой частоты использования функций, от критичности функций и от любых ожидаемых проблем с практичностью.
Такой анализ СМИБдолжен проверить, содержит ли система конкретные средства управления, которые подходят для обработки рисков в рамках области действия СМИБ.
Избежание рисков за счет исключения действий, которые могли бы привести к возникновению рисков.
Кроме того, на основе записей, относящихся к этой области, он обеспечит свидетельства проверки соответствия, а также прослеживаемость корректирующих, предупреждающих действий и действий по улучшению.
Организационные модели, применяемые в проекте, следует обеспечивать через процесс менеджмента модели жизненного цикла. Следует документировать, классифицировать, своевременно и объективно сообщать о проблемах или возможностях и альтернативных направлениях деятельности, которые способны разрешить существующие проблемы.
В текстах стандартов программной инженерии модальный глагол «will/would» придает действию твердую решимость, намерение и переводится на русский язык как «быть» (50 %). В утвердительных приложениях модальный глагол «will» выражает приказ и переводится как «должен» (20 %). Модальный глагол «would» может выражать желание, относящееся к настоящему или к будущему (5 %). С помощью модального глагола «would» можно выразить предположение. В таких случаях при переводе с английского на русский язык модальный глагол «would» переводится как «могли бы» (10 %).
Модальный глагол «will» выражает способность выполнить действие и переводится на русский язык как «способен» (5 %). Такой перевод соответствует переводным эквивалентам модальных глаголов «can» и «to be able to». Также модальный глагол «would» усиливает свое значение, приобретая перевод «следует», что и приводит к неточности смысла (10 %).
В ходе исследования проанализировано 95 примеров употребления модального глагола «need» в текстах стандартов нормативной базы программной инженерии, например:
The maintainer shall conduct analysis and determine which documentation, software units, and versions thereof need to be modified. Decisions may arise as a result of an effectiveness assessment, a technical trade-off, a problem needing to be solved, action needed as a response to risk exceeding the acceptable threshold, a new opportunity or approval for project progression to the next life cycle stage.
In order to be able to claim conformity with a document, the user needs to be able to identify the requirements to be satisfied.
Сопровождающая сторона должна провести анализ и определить, какая документация, программные модули и какая из версий нуждаются в модификации. Потребность в принятии решений может возникать вследствие оценки результативности, принятия компромиссных технических решений, наличия проблем, требующих решений, необходимости реагировать на риски, когда их уровень выходит за допустимые пределы, появления новых возможностей или перехода проекта на следующую стадию жизненного цикла.
Для того чтобы иметь возможность декларировать соответствие с документом, пользователь должен иметь возможность определить требования, которые необходимо выполнить.
Модальный глагол «need» переводится в значении «нуждаться» (55 %). Модальный глагол «need» также приобретает такие значения при переводе на русский язык, как «требоваться» (30 %), «должен» (15 %), в результате чего нарушается ясность в необходимости выполнять требование стандарта.
Can - could. Основным значением глагола «саn» является выражение умения, способности или возможности совершить действие. Несмотря на то, что модальный глагол «саи» является одним из самых используемых модальных глаголов в английском языке, в текстах нормативной базы
программной инженерии используется значительно реже. Он может выражать значение способности и возможности, использоваться для выражения разрешения или запрета [11]. При этом употребление модального глагола can в отрицательных предложениях означает запрет выполнения действия. Модальный глагол «сан» также употребляется, чтобы выразить объективно существующую возможность.
Проанализированы 150 примеров модального глагола «can/could» в текстах стандартов нормативной базы программной инженерии, например:
This Technical Report can be applied to any kind of software for any application. This can be only achieved in a realistic system environment.
This International Standard will provide guidance on principles and processes for the governance of information security, by which organizations can evaluate, direct and monitor the management of information security. Type 1, when the required support can not be obtained for the publication of an International Standard, despite repeated efforts.
Данный Технический отчет может применяться к любому виду программного обеспечения для любого приложения. Этого можно достичь только в реальных условиях работы системы.
Настоящий Международный стандарт будет содержать принципы и процессы управления информационной безопасностью, посредством которых организация сможет оценивать, направлять и контролировать менеджмент информационной безопасности.
Тип 1, если не удается получить необходимую поддержку для опубликования Международного стандарта, несмотря на неоднократные попытки.
The software can not be readily modified under program control.
Technical Reports of types 1 and 2 are subject to review within three years of publication, to decide whether they can be transformed into International Standards. These could be incorporated into such a user's organizational process documentation. Sometimes it takes time to implement a chosen set of controls and during that time the level of risk may be higher than can be tolerated on a long term basis.
The top level description of these groups can be found in subclause 5.2.2 ISO/IEC 9126-1, however, does not describe how any of these subcharacteristics could be measured.
The objective is to provide a road map for the users of this International Standard so that they can orient themselves in it and apply it judiciously.
The Software Problem Resolution Process could be used or easily adapted to manage, track and control software change requests.
Фирменное программное средство не может быть легко модифицировано под управлением какой-либо программы. Технические отчеты 1 и 2 типов являются предметомрас-смотрения в течение трех лет после публикации для вынесения решения о том, можно ли их преобразовать в Международные стандарты.
Эти процессы могли бы учитываться в документации, описывающей организационные процессы пользователей. Иногда требуется время, чтобы внедрить выбранный набор средств управления, и в течение этого периода времени уровень риска может быть выше, чем он должен быть в долгосрочной перспективе.
Описание верхнего уровня этих групп изложено в 5.2.2.
К0/1ЕС 9126-1, однако, не описывает способ измерения этих подхарактеристик.
Целью обзора является предоставление «дорожной карты» пользователям настоящего стандарта для того, чтобы они могли ориентироваться в нем и применять его осмысленно.
Процесс решения проблем в программных средствах может использоваться или легко адаптироваться для менеджмента, отслеживания и управления заявками на изменения в программных средствах.
В исследуемых примерах модальный глагол «can (not)» переводится на русский язык в значении «(не) мочь» (75 %), «можно ли» (0,6 %), «не удается» (5 %), которые соответствуют своим прямым значениям. Модальный глагол «could» также переводится на русский язык в значении «могли бы» (5 %). Модальный глагол «can» приобретает значения, не соответствующие своему прямому значению, такие как «должен» (3 %), или вовсе модальность не выражена при переводе на русский язык (2 %). Модальный глагол «can» переводится как «могли» (1,7 %), «can
not» - «не могли» в Past Simple (0,6 %). Модальный глагол «could» переводится как «мочь» в Present Simple (4,7 %).
Модальный глагол may в текстах стандартов выражает разрешение, предположение, возможность. В повседневном общении глагол «might» передает большую степень неуверенности, сомнения и выражает также упрек [12]. Проанализированы 248 примеров употребления модального глагола «may/might» в текстах стандартов нормативной базы программной инженерии, например:
In exceptional circumstances, the joint technical committee may propose the publication of a Technical Report of one of the following types. Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights.
It is proposed for provisional application so that information and experience of its use in practice may be gathered.
As the probe is moved, this may undergo large (greater than ±6 dB) random fluctuations in amplitude.
Unless requirements for quality fully reflect the needs of the user, quality assurance may not provide adequate confidence.
В особых обстоятельствах совместный технический комитет может предложить опубликование Технического отчета (Technical Report) одного из следующих типов. Внимание обращается на вероятность того, что некоторые составляющие данного документа могут быть предметом патентных прав.
Он предлагается для предварительного применения, для того чтобы можно было накопить информацию и опыт его применения на практике.
По мере перемещения преобразователя возможны значительные колебания амплитуды эхо-сигнала (более ±6 дБ).
До тех пор пока требования к качеству полностью не удовлетворяют потребностям пользователя, гарантия качества не может обеспечить необходимой уверенности.
It is necessary to recognize that some controls may not be applicable to every information system or environment, and might not be practicable for all organizations.
Where required, it maintains records that may be monitored.
Необходимо понимать, что некоторые средства управления могут и не подходить любой информационной системе и среде, и не быть применимыми на практике для всех организаций.
При необходимости ведутся записи с целью контроля.
Модальный глагол «may (not)» при переводе на русский язык приобретает такие значения, как «(не) мочь» (85 %), «может» (5 %), «возможно» (10 %). Модальный глагол «might» переводится на русский язык в значении «можно» (5 %). Модальный глагол
«may» не имеет переводного эквивалента в русском языке (5 %.)
Схема соответствия выражения модальности в английском и русском языках в текстах стандартов нормативной базы программной инженерии представлена на рисунке.
Рисунок. Схема соответствия способов выражения модальности в английском и русском языках на примере нормативной базы программной инженерии
Таким образом, в результате исследования проанализировано 516 примеров употребления модального глагола «shall», 248 - «may/might», 242 -«should», 150 - «can/could», 95 - «need», 67 - «will/ would», 62 - «must», 61 - «have to», 59 - «to be to». Модальный глагол «must» в 80 % переводится в значении «должен», 20 % - «необходимо». Модальный глагол «have to (not)» в 60 % переводится в значении «должен», 20 % - «вынужден», «должен». Модальный глагол «to be to» в 40 % переводится в значении «должен», 20 % - «необходимо», «следует» или не переводится. Модальный глагол «should» в 50 % переводится в значении «следует», 20 % - «должен», 10 % - «необходимо», «надо», «можно». Модальный глагол
«shall (not)» в 85 % переводится в значении «должен», 15 % - «следует», 5 % - «необходимо». Модальный глагол «must» в 80 % переводится в значении «должен», 20 % - «необходимо». Модальный глагол «will/ would» в 55 % переводится в значении «быть», 20 %
- «должен», 10 % - «могли бы», «следует», 5 % -«способен». Модальный глагол «can/could (not)» в 85 % переводится в значении «мочь», 5 % - «не удается», «могли бы», 3 % - «должен», 2 % не переводится. Модальный глагол «may/might» в 85 % переводится в значении «мочь», 10 % - «возможно», 5 %
- «может» или не переводится. Модальный глагол «need (not)» в 45 % переводится в значении «нуждаться», 30 % - «требоваться», 15 % - «должен».
Заключение
Проведенное исследование показало, что способы выражения модальности в английском и русском языках в текстах стандартов программной инженерии имеют ряд несоответствий. Несоответствие в переводе модальных глаголов в текстах стандартов программной инженерии создает ряд сложностей в работе программистов, которые пользуются данными стандартами в своей профессиональной деятельности. При этом причины этих несоответствий остаются невыясненными. Для выяснения предполагаемых причин, выявленных несоответствий необходимо проведение дальнейших исследований в области выражения модальности в текстах стандартов на значительно больших объемах рассматриваемых примеров с дифференциацией по отдельным стандартам. Дифференциация по стандартам позволит исключить влияние человеческого фактора на перевод модальных глаголов. При этом наличие неточностей в переводе модальных глаголов в большинстве текстов стандартов поставит необходимость дальнейшего исследования способа выражения модальности в английском и русском языках, а также разработки методов устранения таких неточностей при переводе нормативной документации.
ЛИТЕРАТУРА
1. Димов Ю. В. Метрология, стандартизация и сертификация. Изд. 2-е. СПб. : Питер, 2004. 432 с.
2. Бутенко Ю. И., Семенова Е. Л. Влияние лингвистических особенностей текстов стандартов на информационный поиск // Филологические науки. Научные доклады Высшей школы. 2019. № 4. С. 29-35.
3. Бутенко Ю. И., Шостак И. В. Семантическая модель языковых объектов для автоматизации процесса сертификации систем критического применения // Инженерный журнал : наука и инновации. 2013. Вып. 12 (24) С. 12-14.
4. Митрошкина Т. В. Английские модальные глаголы. Минск : ТетраСистемс, 2011. 56 с.
5. Черненко Д. В. Модальные глаголы английского языка. М. : EksmoEducation, 2008. С. 112-127.
6. Климзо Б. Н. Ремесло технического перевода. М. : Р. Валент, 2006. С. 233-237.
7. Семенова М. Ю. Основы перевода текста : учебник. Ростов н/Д. : Феникс, 2009. 133 с.
Московский государственный технический университет имени Н. Э. Баумана
БутенкоЮ. И., кандидат технических наук, доцент кафедры «Романо-германскиеязыки», ассистент кафедры иностранных языков Российского университета дружбы народов
E-mail: iuliiabutenko2015@yandex.ru
8. Селиванова Е. А. Лингвистическая энциклопедия. Полтава : Довкиля-К, 2010. 855 с.
9. Нелюбин Л. Л. Перевод и прикладная лингвистика. М. : Высш. школа, 1983. 217 с.
10. Смирнова Е. Д. Основы логической семантики. М. : Высшая школа, 1990. 108 с.
11. Азимов Э. Г., Щукин А. Н. Новый словарь методических терминов и понятий (теория и практика обучения языкам). М. : ИКАР, 2010. 220 с.
12. Richard J. C., Richard S. Longman Dictionary of Language Teaching and Applied Linguistics. London : Longman, 2010. 622 р.
REFERENCES
1. Dimov Y. V. Metrology, standardization and certification. S-Pb: Peter, 2nd edition, 2004. 432 p.
2. Butenko Yu. I., Semjenova E. L. Influence of linguistic features of standards on information retrieval. In: Philological science. Scientific reports of the higher school. 2019. No. 6. Pp. 29-35.
3. Butenko Yu. I., Shostak I. V. Semantic model of language objects for automating the certification process for critical application systems. In: Engineering magazine: science and innovation. 2013. Iss. 12 (24). Pp. 12-14. Available at: http://engjournal.ru/catalog/appmath/ hidden/1165.html
4. Microskin T. V. English modal verbs. Minsk: TetraSystems, 2011. 56 p.
5. Chernenko D. V. Modal verbs in English. M.: Eksmo Education, 2008. Pp. 112-127.
6. Klimzo B. N. Craft technical translator. M.: R. Valent, 2006. Pp. 233-237.
7. Semjenova M. Yu. A basic text translation: Textbook. Rostov-on-Don: Feniks, 2009. 133 p.
8. Selivanova E. A. The Linguistic encyclopedia. Poltava: Dovkillya-K, 2010. 855 p.
9. Nelyubin. L. L. Translation and applied linguistics. M.: High school, 1983. 217 p.
10. Smirnova E. D. The Foundations of Logical Semantics. M.: High school, 1990. 108 p.
11. Azimov E. G., Shchukin A. N. Dictionary of methodological terms (theory and practice of language teaching). M.: ICAR, 2010. 220 p.
12. Richard J. C., Richard S. Longman Dictionary of Language Teaching and Applied Linguistics. London: Longman, 2010. - 622 p.
Bauman Moscow State Technical University
Butenko Yu. I., Candidate of Technical Sciences, Associate Professor of the Romano-Germanic languages Department, Assistant of the of Foreign Languages Department of Peoples' Friendship University of Russia
E-mail: iuliiabutenko2015@yandex.ru
Авагян Н. А., студент кафедры «Романо-германские языки»
E-mail: nareavagyan98@mail.ru
Поступила в редакцию 20 января 2021 г.
Принята к публикации 22 марта 2021 г.
Для цитирования:
Бутенко Ю. И., Авагян Н. А. Способы выражения модальности в параллельных текстах стандартов (на примере нормативной базы программной инженерии) // Вестник Воронежского государственного университета. Серия: Лингвистика и межкультурная коммуникация. 2021. № 2. С. 46-55. DOI: https://doi.org/10.17308/ lic.2021.2/3414
Avagyan N. A., Student of the Romano-Germanic languages Department
E-mail: nareavagyan98@mail.ru
Received: 20 January 2021
Accepted: 22 March 2021
For citation:
Butenko Yu. I., Avagyan N. A. Ways of expressing modality in parallel standards texts (on normative framework of software engineering). Proceedings of Voronezh State University. Series: Linguistics and Intercultural Communication. 2021. No. 2. Pp. 46-55. DOI: https://doi.org/10.17308/ lic.2021.2/3414
