| Russian | English |
| как и всё производство ПО, структурное проектирование – непрерывная, итерационная и пошаговая работа. Первоначально структурные решения принимаются на основе широкого взгляда на структуру ПО. Одно из первых принятых решений касается структурирования системы на уровни модулей и установления принципов связи между модулями. это тема данной главы. Более детальные структурные решения, типа связи внутри модуля, рассматриваются позже в соответствующих местах книги | Like all software production, architectural design is a continuing, iterative and incremental, effort. Early architectural decisions take a broad view on the software architecture. One of the first decisions to be taken relates to structuring the system into layers of modules and establishing principles of inter-module communication. This is the concern of this chapter. More detailed architectural solutions, such as intra-module communication, are discussed in relevant places later in the book (см. Maciaszek L.A. and Liong B.L. 2005: Practical Software Engineering) |
| компонент Инфраструктуры обработки событий общего формата, который принимает события из источников событий, выполняет и проверяет их, а затем отправляет их на сервер событий в соответствии с критериями фильтрации | A component of the Common Event Infrastructure that receives events from event sources, completes and validates the events, and then sends events to the event server based on filter criteria (см. event emitter ssn) |
| Обобщая, положение объекта является объединением положений действий, в которых объект может принимать участие | By extension, the location of an object is the union of the locations of the actions in which the object may take part (см. ISO/IEC 10746-2, ГОСТ Р ИСО/МЭК 10746-2-2000 ssn) |
| Одно популярное практическое правило состоит в том, чтобы заблаговременно определить около 80% требований, предусмотреть время для более позднего определения дополнительных требований и выполнять по мере работы систематичный контроль изменений, принимая только самые важные требования | one common rule of thumb is to plan to specify about 80 percent of the requirements up front, allocate time for additional requirements to be specified later, and then practice systematic change control to accept only the most valuable new requirements as the project progresses (см. Code Complete / Steve McConnell.-2nd ed. 2004) |
| при наличии свойств, критичных по отношению к системе, принимаются во внимание структуры жизненного цикла, рекомендованные или установленные в качестве обязательных стандартами, соответствующими области критичности | in the case of properties critical to the system, take due account of the life cycle structures recommended or mandated by standards relevant to the dimension of the criticality (см. ISO/IEC 15288:2002E) |
| принимать анонимную функцию в качестве аргумента | take a lambda expression as an argument (Alex_Odeychuk) |
| принимать анонимную функцию в качестве аргумента | take a lambda as an argument (англ. термин взят из кн.: Groves M.D. AOP in .NET: Practical Aspect-Oriented Programming Alex_Odeychuk) |
| принимать в качестве | take as (Alex_Odeychuk) |
| принимать в качестве аргумента | take as an argument (корпорации Oracle Alex_Odeychuk) |
| принимать в качестве параметра идентификатор времени | accept a clock ID (для функции управления временем ssn) |
| принимать лямбда-выражение в качестве аргумента | take a lambda expression as an argument (Alex_Odeychuk) |
| принимать лямбда-выражение в качестве аргумента | take a lambda as an argument (англ. термин взят из кн.: Groves M.D. AOP in .NET: Practical Aspect-Oriented Programming Alex_Odeychuk) |
| принимать предикат в качестве аргумента | take a predicate as an argument (корпорации Oracle Alex_Odeychuk) |
| Решения по адаптации принимаются в соответствии с процессом принятия решений | Make tailoring decisions in accordance with the Decision-making Process (см. ISO/IEC 15288:2002E ssn) |
| эта диаграмма показывает фрагмент логики переходов для задачи, которая управляет перемещением тележки погрузочно-разгрузочных операций. Тележка перемещается от одного положения до другого, принимая детали в одном положении и сваливая их в другом | this diagram shows a fragment of the transition logic for a task that controls the movement of a materials handling vehicle. The vehicle moves from one position to another, picking up parts in one position and dropping them off at another (см. Auslander D.M., Ridgely J.R., Ringgenberg J.D. Control Software for Mechanical Systems. Object-Oriented Design in a Real-Time World) |
