| Russian | English |
| архитектура на основе разделения обязанностей команд и запросов | CQRS (архитектура многоуровневых систем Alex_Odeychuk) |
| выполнять свои производственные обязанности с помощью дистанционного доступа | telework (напр., на дому ssn) |
| иметь многочисленные обязанности | handle multiple responsibilities (While the code is organized into functions, some functions are quite long and handle multiple responsibilities. Consider breaking down functions into smaller, more focused functions to improve readability and maintainability. Alex_Odeychuk) |
| методология проектирования от обязанности | responsibility-driven design technique (a design technique in object-oriented programming. Responsibility-driven design is inspired by the client/server model. It focuses on the contract by asking: What actions is this object responsible for? What information does this object share? Responsibility-driven design is in direct contrast with data-driven design, which promotes defining the behavior of a class along the data that it holds. Data-driven design is not the same as data-driven programming, which is concerned with using data to determine control flow not class design Alex_Odeychuk) |
| обязанности и взаимодействие функциональных групп | group responsibilities and interactions (ssn) |
| обязанности организации | responsibilities of the organization (ssn) |
| обязанности организаций | responsibilities of the organizations (ssn) |
| обязанности организаций, участвующих | responsibilities of the organizations involved (в договоре ssn) |
| обязанность архитектора | duty of an architect (ssn) |
| обязанность класса | class responsibility (UML EGK) |
| обязанность по работе | job responsibility (ssn) |
| организованный согласно принципу единственной обязанности | be focused around the single responsibility principle (InfoWorld; принцип единственной обязанности – принцип объектно-ориентированного программирования, который гласит, что каждый объект должен иметь одну и только одну обязанность и эта обязанность должна быть полностью инкапсулирована в модуль, класс или сетевую службу. Все методы и свойства класса (экземпляра класса) должны быть направлены исключительно на выполнение этой обязанности. Объединение нескольких сущностей, имеющих разные сферы ответственности в одном классе, модуле или службе, считается неудачным проектным решением Alex_Odeychuk) |
| основная обязанность по работе | main job responsibility (ssn) |
| отсутствие должного разделения обязанностей | missing separation of concerns (ssn) |
| первоочередная обязанность | foremost duty (ssn) |
| первоочередная обязанность архитектора | foremost duty of an architect (ssn) |
| пользовательские обязанности | user responsibility (ssn) |
| принцип единственной обязанности | SIP (сокр. от "single responsibility principle"; принцип объектно-ориентированного программирования, который гласит, что каждый объект должен иметь одну и только одну обязанность и эта обязанность должна быть полностью инкапсулирована в модуль или класс. Все методы и свойства класса (экземпляра класса) должны быть направлены исключительно на выполнение этой обязанности. Объединение нескольких сущностей, имеющих разные сферы ответственности в одном классе или модуле, считается неудачным проектным решением Alex_Odeychuk) |
| принцип единственной обязанности | single responsibility principle (принцип объектно-ориентированного программирования, который гласит, что каждый объект должен иметь одну и только одну обязанность и эта обязанность должна быть полностью инкапсулирована в модуль или класс. Все методы и свойства класса (экземпляра класса) должны быть направлены исключительно на выполнение этой обязанности. Объединение нескольких сущностей, имеющих разные сферы ответственности в одном классе или модуле, считается неудачным проектным решением. Alex_Odeychuk) |
| принцип разделения обязанностей | separation of concerns principle (англ. термин взят из кн.: De Sanctis V. ASP.NET Core and Angular 2 Alex_Odeychuk) |
| принцип разделения обязанностей | single responsibility principle (каждый объект в программе должен иметь единственную обязанность. Если объект выполняет множество различных обязанностей – его необходимо разделить. Например, объект печати отчётов ответственен за формат и за содержимое отчётов – это неправильно. За формат должен отвечать один объект, за содержимое – другой Alex_Odeychuk) |
| принцип разделения обязанностей | SoC principle (сокр. от "separation of concerns principle" Alex_Odeychuk) |
| принцип разделения обязанностей в коде | principle of separation of concerns within code (Alex_Odeychuk) |
| проектирование от обязанности | responsibility-driven design (a design technique in object-oriented programming. Responsibility-driven design is inspired by the client/server model. It focuses on the contract by asking: What actions is this object responsible for? What information does this object share? Responsibility-driven design is in direct contrast with data-driven design, which promotes defining the behavior of a class along the data that it holds. Data-driven design is not the same as data-driven programming, which is concerned with using data to determine control flow not class design. Alex_Odeychuk) |
| проектные организации и распределение обязанностей | project organizations and responsibilities (ssn) |
| профиль обязанностей | incumbent profile (ssn) |
| профиль ролевых обязанностей | role incumbent profile (ssn) |
| разделение обязанностей | SoC (сокр. от "separation of concerns"; англ. термин взят из кн.: De Sanctis V. ASP.NET Core and Angular 2 Alex_Odeychuk) |
| разделение обязанностей | responsibility (ssn) |
| разделение обязанностей | separation of concerns (ssn) |
| разделение обязанностей в базе кода | separation of concerns in a code base (Alex_Odeychuk) |
| разделение обязанностей в коде | separation of concerns within code (Alex_Odeychuk) |
| разделение обязанностей команд и запросов | CQRS (сокр. от "command query responsibility segregation"; из кн.: Эспозито Д., Сальтарелло А. Microsoft .NET: архитектура корпоративных приложений Alex_Odeychuk) |
| разделение обязанностей при проектировании подсистем | separation of concerns in subsystem design (ssn) |
| распределение обязанностей | assigning responsibilities (ssn) |
| распределение обязанностей | responsibilities (ssn) |
| ролевая обязанность | role incumbent (ssn) |
| ролевая обязанность реальный человек пользователь в определённой роли пользователя | role incumbent: The actual person user in a particular user role (см. "Software for Use: A Practical Guide to the Models and Methods of Usage- Centered Design" by Larry L. Constantine, Lucy A. D. Lockwood 1999 ssn) |
| ролевая обязанность – реальный человек пользователь в определённой роли пользователя | role incumbent: The actual person user in a particular user role (см. "Software for Use: A Practical Guide to the Models and Methods of Usage- Centered Design" by Larry L. Constantine, Lucy A. D. Lockwood 1999 ssn) |
| роли и обязанности в тестировании | roles and responsibilities in testing (ssn) |
| соблюдать принцип единственной обязанности | adhere to the single responsibility principle (принцип единственной обязанности – это принцип объектно-ориентированного программирования, который гласит, что каждый объект должен иметь одну и только одну обязанность и эта обязанность должна быть полностью инкапсулирована в модуль или класс. Все методы и свойства класса (экземпляра класса) должны быть направлены исключительно на выполнение этой обязанности. Объединение нескольких сущностей, имеющих разные сферы ответственности в одном классе или модуле, считается неудачным проектным решением. Если класс выполняет множество различных обязанностей – его необходимо разделить. Например, класс печати отчётов ответственен за формат и за содержимое отчётов – это неправильно. За формат должен отвечать один класс, за содержимое – другой Alex_Odeychuk) |
| составление схемы обязанностей | responsibility charting (ssn) |
| Сохраняя за собой основную обязанность по работе, служащий должен иметь план на случай отказа системы | the clerk still has a main job responsibility, and must have a plan in case the system fails to perform its part (см. Writing Effective Use Cases by Alistair Cockburn 2001) |
| структурная ролевая модель – структурная модель ролей пользователей с точки зрения определённых категорий явно выраженных или различимых характеристик, включая профиль ролевых обязанностей, профиль ролевой квалифицированности, профиль ролевого взаимодействия, информационный профиль роли, профиль ролевой поддержки, профиль критериев практичности и связанные между собой роли ролевая карта | structured role model: A structured model of user roles in terms of specific categories of salient or distinguishing characteristics, including role incumbent profile, role proficiency profile, role interaction profile, role information profile, role support profile, usability criterion profile, and related roles role map (см. "Software for Use: A Practical Guide to the Models and Methods of Usage- Centered Design" by Larry L. Constantine, Lucy A. D. Lockwood 1999 ssn) |
| структурная ролевая модель структурная модель ролей пользователей с точки зрения определённых категорий явно выраженных или различимых характеристик, включая профиль ролевых обязанностей, профиль ролевой квалифицированности, профиль ролевого взаимодействия, информационный профиль роли, профиль ролевой поддержки, профиль критериев практичности и связанные между собой роли ролевая карта | structured role model: A structured model of user roles in terms of specific categories of salient or distinguishing characteristics, including role incumbent profile, role proficiency profile, role interaction profile, role information profile, role support profile, usability criterion profile, and related roles role map (см. "Software for Use: A Practical Guide to the Models and Methods of Usage- Centered Design" by Larry L. Constantine, Lucy A. D. Lockwood 1999 ssn) |
| типичные обязанности | typical duties (ssn) |
| уровни разделения обязанностей | responsibility layers (ssn) |
| цепочка обязанностей: шаблон проектирования | chain of responsibility (можно избежать жесткой зависимости отправителя запроса от его получателя, при этом запросом начинает обрабатываться один из нескольких объектов. Объекты-получатели связываются в цепочку, и запрос передается по цепочке, пока какой-то объект его не обработает ssn) |
