| English | Russian |
| calls to predicates encapsulated in modules | вызов предикатов, инкапсулированных в модулях (Alex_Odeychuk) |
| coherence in one software module | уровень связности каждого программного модуля (coherence in one software module shall be strong – уровень связности каждого программного модуля должен быть высоким // IEC 61508-7:2010 Alex_Odeychuk) |
| connections between software modules should be limited and strictly defined, coherence in one software module shall be strong | связи между программными модулями должны быть ограничены и строго определены, уровень связности каждого программного модуля должен быть высоким (см. IEC 61508-7: 2010 ssn) |
| drop-in module | подключаемый модуль (из кн.: Шефер К., Хо К., Харроп Р. Spring 4 для профессионалов  codeproject.com Alex_Odeychuk) |
| 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) |
| order in which modules should be tested and integrated | порядок тестирования и интеграции модулей (ssn) |
| our goal in decomposing a program is to create modules that are themselves small programs that interact with one another in simple, well-defined ways | Нашей целью при декомпозиции программы является создание модулей, которые в свою очередь представляют собой небольшие программы, взаимодействующие друг с другом по хорошо определённым и простым правилам (см. "Abstraction and Specification in Program Development" by Barbara Liskov & John Guttag 1986) |
| program is defined in terms of a few high-level modules | программа реализуется в виде нескольких модулей высокого уровня (ssn) |
| synchronization in modules | синхронизация в модулях (ssn) |
| Thus each module should perform a single function in the broad sense of an identified job of work | Следовательно, каждый модуль должен выполнять одну функцию, понимаемую в широком смысле как некоторый фрагмент работы (ssn) |
| trade-offs that suggest possible decompositions of modules and architectures to satisfy incompatible sets of requirements found in the domain | компромиссы, связанные с возможностью декомпозиции модулей и архитектур для обеспечения соответствия несовместимым наборам требований, существующим в пределах данной предметной области (ssn) |
| type implemented in another module within the calling assembly | тип, реализованный в другом модуле вызывающей сборки (из кн.: Рихтер Дж. CLR via C#. – 4-е изд. – СПб.: Питер, 2013 Alex_Odeychuk) |
