О словаре | FAQ | Вход | Регистрация |Настройки
Словарь Мультитран
Dicts Forum Buy Download Guestbook Contacts в тестовом режиме открыт новый сайт Мультитрана
   Eng 
 Термины по тематике Программирование, содержащие не может быть!: все формы слов (12) | только заданная форма слов (10) | в заданном порядке
 Базисный функциональный блок не может быть распределен, он может работать только на одном ресурсе. Базисные функциональные блоки определяют основные блоки, из которых могут быть созданы большие композиционные блокиA basic function block cannot be distributed, it can only run on a single resource. Basic function blocks define the fundamental blocks from which large composite blocks can be built (см. Robert W. Lewis: Modelling control systems using IEC 61499. Applying function blocks to distributed systems ssn)
 взаимодействие "сообщение не удалось отправить""email could not be sent" interaction (ssn)
 Для структурного проекта системы напрашивается аналогия со строительной индустрией. Дом не может быть построен, если архитектор не спроектировал его возможно, навес – да, но не дом . Точно так же любая разумно большая система ПО не может быть построена без предшествующего структурного проектирования. Структура ПО – это основа, на которой должны базироваться все остальные проектные и программные решенияThe architectural design begs for the analogy from the building industry. A house cannot be built unless an architect designed it perhaps a shed – yes, but not a house . Similarly, any reasonably large software system cannot be built without a prior architectural design. Software architecture is a foundation on which all other design and programming solutions must be based (см. Maciaszek L.A. and Liong B.L. (2005): Practical Software Engineering ssn)
 К сожалению, структуры зависимостей только сверху вниз не совсем реалистичны. В действительности будут существовать зависимости снизу вверх, но они могут быть сделаны относительно безопасными квалифицированным проектированием и программированием. Желательный результат таков, чтобы более высокие уровни зависели от более низких уровней, в то время как более низкие уровни все ещё могли бы связываться с более высокими уровнями, но без создания неуместных неуправляемых зависимостейUnfortunately, the top-down only dependency structure is not quite realistic. In reality, the bottom-up dependencies will exist, but they can be made relatively harmless by skilful design and programming. A desired outcome is that higher layers depend on lower layers while lower layers can still communicate with higher layers without exerting undue unmanageable dependencies (см. Maciaszek L.A. and Liong B.L. (2005): Practical Software Engineering ssn)
 Например, данная обязательная принадлежность может дополнительно означать, что принадлежность является фиксированной, т.е. если объект связан с целевым объектом в ассоциации, он не может быть повторно связан с другим целевым объектом в той же ассоциацииFor example, a particular mandatory membership may additionally imply that the membership is fixed, i.e. once an object is linked to a target object in the association it cannot be reconnected to another target object in the same association (см. Maciaszek; L.A.: Requirements Analysis and System Design; 3rd ed. (2007) ssn)
 недостижимый код: код, который не может быть достигнут и исполненunreachable code: Code that cannot be reached and therefore is impossible to execute (Standard glossary of terms used in Software Testing ssn)
 Помещение разработки ПО в среду бизнес-моделирования означает, что процесс создания и эксплуатации ПО получен из более широкой бизнес-модели, и он старается поддерживать и реализовывать конкретный бизнес-процесс в этой модели. Отсюда следует, что программный продукт/сервис не может быть только информационным сервисом. Он должен также реализовывать бизнес-операции или содействовать имPlacing software development in the context of business modeling means that a software process is derived from a wider business model and it tries to support and implement a particular business process in that model. This means that a software product/service cannot be just an information service. It should also implement and assist in business actions (см. Maciaszek L.A. and Liong B.L. (2005): Practical Software Engineering ssn)
 Поскольку выявление поведения программы во время выполнения – "не лучшая забава" для эксплуатационного персонала системы или менеджера проекта, практика явных ассоциаций между классами, занятыми в передаче сообщений, более предпочтительна. Без явных ассоциаций анализ воздействий из-за изменений в поставляемом коде может быть невозможенAs the discovery of the program’s runtime behavior is “not much fun” for a system maintainer or a project manager, the practice of explicit associations between classes engaged in message passing is so much more important. Without explicit associations, the impact analysis due to a change in the supplier code may be unachievable (см. Maciaszek L.A. and Liong B.L. (2005): Practical Software Engineering ssn)
 Последствие делегирования таково, что клиент может и не знать своего реального поставщика и он даже может не хотеть знать это, пока не получит "требуемое" . В отличие от рис. 9.7 знание реального поставщика может быть недоступно из статического анализа программного кода и может быть скрыто за динамикой наследования в частности, наследования интерфейса и полиморфизмаThe consequence of delegation is that a client might not know its real supplier and it might not even care to know as long as the “goods” are supplied . Unlike in Figure 9-7, the knowledge of the real supplier may not be available from a static analysis of the program code and be hidden behind the dynamicity of inheritance in particular interface inheritance and polymorphism (см. Maciaszek L.A. and Liong B.L. (2005): Practical Software Engineering ssn)
 Программная инженерия может заниматься "нечёткими" проблемами, но это не подразумевает, что они должны быть менее строгими или недоказуемымиSoftware engineering may be tackling “fuzzy” problems but this does not mean that is must be less rigorous or not provable (см. Maciaszek L.A. and Liong B.L. (2005): Practical Software Engineering ssn)
 Программное обеспечение только тогда должно стать непригодным или недопустимым, когда бизнес создаёт новые условия или меняется внешняя среда. Если речное русло переместится на десять метров из-за недавнего наводнения, инженер-строитель не может быть обвинён, и не следует ожидать, что существующий мост можно будет легко переместить, чтобы приспособить к новому руслуThe software has only become unusable or unacceptable because the business conditions or external environment changed. If a river corridor moved by ten meters because of the recent flooding, a civil engineer cannot be blamed and must not be expected to effortlessly move the existing bridge to span the new corridor (см. Maciaszek L.A. and Liong B.L. (2005): Practical Software Engineering ssn)
 Старшинство операторов является фиксированным и не может быть изменено пользователем, но наряду с этим для управления порядком сопоставления операторов и операндов могут быть использованы круглые скобкиThe precedence of an operator is fixed and may not be changed by the user, but parentheses can be used to control the association of operators and operands (см. IEЕЕ Std. 1076-87. IEЕЕ Standard VHDL. Language Reference Manual ssn)
     
 Оценить сайт