| Russian | English |
| Действий при входе и выходе невозможно избежать, даже при выбрасывании исключений. Эти действия представляют собой механизм инкапсуляции, служащий для спецификации поведения конечного автомата, и гарантируют выполнение неких обязательных действий при любых условиях | Entry and exit actions may not be evaded by any means, including the occurrence of exceptions. They provide an encapsulation mechanism for the specification of state machine behavior, with a guarantee that necessary actions will be performed under all circumstances (см. "The UML Reference Manual" by J.Rumbaugh, Ivar Jacobson, Grady Booch 1999 ssn) |
| как последствие разрешения атрибутов в интерфейсах, можно создать ассоциации между интерфейсами и между интерфейсом и классом. Атрибуты, определённые как другой интерфейс или класс, представляют ассоциации. В UML 2.0 можно организовывать переход от интерфейса к классу через ассоциацию. В Java это невозможно | as a consequence of allowing attributes in interfaces, it is possible to create associations between interfaces and between an interface and a class. Attributes typed as another interface or class represent associations. In the UML 2.0 it is possible to navigate from an interface to a class via an association. This is not possible in Java (см. Maciaszek L.A. and Liong B.L. 2005: Practical Software Engineering) |
| невозможное событие | can't happen (ssn) |
| практически невозможный 100%-й коэффициент конверсии | near-impossible 100 percent conversion rate (ssn) |
| эти утверждения, особенно и в большой степени, истинны для современного объектно-ориентированного создания ПО. Понятие объекта вооружает инженера ПО множеством очень мощных абстракций программирования. Но если они используются неблагоразумно, получаются программы, которые невозможно ни понять, ни обслуживать даже теми программистами, которые написали их | these observations are particularly, and painfully, true for modern object-oriented software production. The object paradigm equips a software engineer with a multitude of very powerful programming abstractions, which – when used unwisely – result in programs impossible to understand and maintain, even by programmers who wrote them (см. Maciaszek L.A. and Liong B.L. 2005: Practical Software Engineering) |
| эти утверждения, особенно и в большой степени, истинны для современного объектно-ориентированного создания ПО. Понятие объекта вооружает инженера ПО множеством очень мощных абстракций программирования. Но если они используются неблагоразумно, получаются программы, которые невозможно ни понять, ни обслуживать даже теми программистами, которые написали их | these observations are particularly, and painfully, true for modern object-oriented software production. The object paradigm equips a software engineer with a multitude of very powerful programming abstractions, which when used unwisely result in programs impossible to understand and maintain, even by programmers who wrote them (см. Maciaszek L.A. and Liong B.L. 2005: Practical Software Engineering) |
