| Russian | English |
| в современной практике CASE– и инструментальные средства разработки программ могут существенно помочь в реализации рефакторинга. Многие инструментальные средства содержат каталоги поддерживаемых рефакторингов. Фаулер 1999 является основным источником ссылок, который перечисляет и документирует более шестидесяти методов рефакторинга. Следующее обсуждение иллюстрирует использование методов рефакторинга, рассматривая только три из них | in contemporary practice, CASE and programming development tools can effectively assist in performing refactorings. Many tools contain catalogs of supported refactorings. Fowler 1999 is a principal source of reference that lists and documents in excess of sixty refactoring methods. The following discussion illustrates the use of refactoring methods by discussing just three of them (см. Maciaszek L.A. and Liong B.L. 2005: Practical Software Engineering) |
| в современной практике CASE и инструментальные средства разработки программ могут существенно помочь в реализации рефакторинга. Многие инструментальные средства содержат каталоги поддерживаемых рефакторингов. Фаулер 1999 является основным источником ссылок, который перечисляет и документирует более шестидесяти методов рефакторинга. Следующее обсуждение иллюстрирует использование методов рефакторинга, рассматривая только три из них | in contemporary practice, CASE and programming development tools can effectively assist in performing refactorings. Many tools contain catalogs of supported refactorings. Fowler 1999 is a principal source of reference that lists and documents in excess of sixty refactoring methods. The following discussion illustrates the use of refactoring methods by discussing just three of them (см. Maciaszek L.A. and Liong B.L. 2005: Practical Software Engineering) |
| Вопросы синхронизации важны для любой ОС, и поэтому многие руководства по ОС содержат их подробное обсуждение в рамках более общего контекста | Synchronization issues are independent of the OS, and many OS texts discuss the issue at length and within a more general framework (см. Windows System Programming, 4th Edition by Johnson M. Hart 2010 ssn) |
| Динамическая система составляется и осмысливается в терминах понятий высокого уровня, которые в свою очередь составляются и осмысливаются в терминах понятий более низкого уровня и т.д. | the dynamic system is constructed and understood in terms of high level concepts, which are in turn constructed and understood in terms of lower level concepts, and so forth. |
| задача, более или менее точно определённая и понимаемая в терминах некоторых проблемно-ориентированных понятий | problem, more or less precisely defined and understood in terms of certain problem oriented concepts (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) |
| как и всё производство ПО, структурное проектирование – непрерывная, итерационная и пошаговая работа. Первоначально структурные решения принимаются на основе широкого взгляда на структуру ПО. Одно из первых принятых решений касается структурирования системы на уровни модулей и установления принципов связи между модулями. это тема данной главы. Более детальные структурные решения, типа связи внутри модуля, рассматриваются позже в соответствующих местах книги | 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) |
| конструктив, выбирающий с взаимовключением: данный конструктив состоит из ряда процедурных частей и управляющей части с набором условий, значениея которых выбирают одну и более или ни одной процедурных частей, выполняемых в произвольной последовательности | multiple inclusive selective construct: This construct consists of a number of procedure parts and a control part with a set of conditions, the values of which select zero or more procedure parts to be executed in an undefined sequence (см. ISO/IEC 8631:1989 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) |
| перед началом разработки программного проекта мы имеем задачу, более или менее точно определённую и понимаемую в терминах некоторых проблемно-ориентированных понятий, и язык программирования, возможно универсальный, который обеспечивает нас некоторыми машинно-ориентированными основными понятиями, точно определёнными и понимаемыми | at the outset of a programming project there is a problem, more or less precisely defined and understood in terms of certain problem oriented concepts, and a programming language, perhaps a general purpose one, providing some machine oriented basic concepts, hopefully precisely defined and completely understood |
| при хорошем исполнении в результате можно получить более простой программный код, меньшую продолжительность тестирования и облёгченное сопровождение | when done well, it can result in simpler code, faster testing, and easier maintenance |
| тестирование "сверху вниз": инкрементальный подход к интеграционному тестированию, в котором компоненты из верхнего уровня иерархии объектов тестируются в первую очередь, с использованием заглушек вместо компонентов более низкого уровня. Протестированные компоненты используются для тестирования компонентов более низкого уровня и данный процесс повторяется до тех пор, пока не будут протестированы компоненты самого низшего уровня | top-down testing: An incremental approach to integration testing where the component at the top of the component hierarchy is tested first, with lower level components being simulated by stubs. Tested components are then used to test lower level components. The process is repeated until the lowest level components have been tested (см. Standard glossary of terms used in Software Testing ssn) |
| управляющая часть с набором условий, значениея которых выбирают одну и более или ни одной процедурных частей, выполняемых в произвольной последовательности | control part with a set of conditions, the values of which select zero or more procedure parts to be executed in an undefined sequence (ssn) |
| Учитывая это, природа компьютеризации проектов современных механических систем становится более понятной. Вычислительные способности и ограничения должны рассматриваться на всех стадиях процесса проектирования и реализации. В частности, эффективность окончательной промышленной системы будет существенно зависеть от качества функционирования программного обеспечения в реальном масштабе времени, которое управляет механизмом | with this context, the compucentric nature of modern mechanical systems designs becomes clearer. Computational capabilities and limitations must be considered at all stages of the design and implementation process. In particular, the effectiveness of the final production system will depend very heavily on the quality of the real time software that controls the machine (см. Auslander D.M., Ridgely J.R., Ringgenberg J.D. Control Software for Mechanical Systems. Object-Oriented Design in a Real-Time World) |
