| English | Russian |
| A time-varying control system is a system in which one or more of the parameters of the system may vary as a function of time | Нестационарная система управления – это система, в которой один или более параметров являются функциями времени (см. Modern Control Systems by Richard C. Dorf & Robert H. Bishop 2008 ssn) |
| A time-varying control system is a system in which one or more of the parameters of the system may vary as a function of time | Нестационарная система управления это система, в которой один или более параметров являются функциями времени (см. Modern Control Systems by Richard C. Dorf & Robert H. Bishop 2008 ssn) |
| Architecture of the system should be addressed early in the process. Booch et al. 1999 consider architecture as one of only three main characteristics of any development process favoring the UML. The three characteristics of the process are: | Структуру системы следует рассматривать на ранних этапах процесса. Буч и др. 1999 рассматривают структуру как единство трёх основных характеристик любого процесса разработки, использующего UML. Эти три характеристики процесса следующие: (см. Maciaszek L.A. and Liong B.L. 2005: Practical Software Engineering ssn) |
| as expected by the Extract Class refactoring, CAdmin maintains association links to new classes. The links are supported by two methods: getMsgSeeker and getMsgSender. The former gets the CMsgSeeker object, the one responsible for retrieving outmessages for presentation layer. The latter gets the CMsgSender object responsible for emailing outmessages | как ожидается, с помощью рефакторинга Класс извлечения CAdmin обеспечивает связи ассоциации с новыми классами. Связи поддерживаются двумя методами: getMsgSeeker и getMsgSender . Первый получает объект CMsgSeeker, который отвечает за извлечение исходящих сообщений для уровня представления. Второй получает объект CMsgSender, ответственный за исходящие сообщения, передаваемые по электрон почте (см. Maciaszek L.A. and Liong B.L. 2005: Practical Software Engineering) |
| as we shall see throughout the book, a great many algorithms are based on the principle of recursively decomposing a large problem into one or more smaller ones, using solutions to the subproblems to solve the original problem | как мы увидим далее в этой книге, многие алгоритмы основаны на принципе рекурсивного разбиения большой задачи на меньшие, когда решения подзадач используются для решения исходной задачи (см. Algorithms in C++, Parts 1–4: Fundamentals, Data Structure, Sorting, Searching Third Edition by Robert Sedgewick 1998) |
| data from one component interacting with another component in a local system, distributed system, and/or across a network such as the Internet with other systems via the signal | данные от одного компонента, взаимодействующего с другим компонентом в локальной системе, распределенной системе и / или через сеть, такую как Интернет, с другими системами посредством сигнала |
| depicted as one aggregate class | представленный одним агрегатным классом (ssn) |
| 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) |
| 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 | Одно популярное практическое правило состоит в том, чтобы заблаговременно определить около 80% требований, предусмотреть время для более позднего определения дополнительных требований и выполнять по мере работы систематичный контроль изменений, принимая только самые важные требования (см. Code Complete / Steve McConnell.-2nd ed. 2004) |
| One solution, which we won't use, is to create a large array of pointers and assign values to the pointers, one by one, as new structures are allocated | Одно из возможных решений, которое, однако, мы применять не будем, предполагает создание большого массива указателей и присваивание значений указателям друг за другом по мере выделения памяти под новые структуры (C Primer Plus by Stephen Prata (2013) ssn) |
| one-dimensional array as function | одномерный массив как функция (ssn) |
| proper behaviors as an application moves from one state to another | соответствующие варианты поведения при переходах приложения из одного состояния в другое (ssn) |
| the great strength of the state machine approach is that it enables you to come up with an explicit definition of valid states for some aspect of your application and enforce proper behaviors as an application moves from one state to another | Мощь подхода, использующего конечный автомат, обусловлена тем, что он позволяет в явном виде определить действительные состояния для некоторого аспекта вашего приложения и задать соответствующие варианты поведения при переходах приложения из одного состояния в другое (см. "Writing Mobile Code Essential Software Engineering for Building Mobile Applications" by Ivo Salmre 2005) |
