Принцип ортогональности ошибки и наблюдения

From Wikipedia, the free encyclopedia

In statistics and signal processing, the orthogonality principle is a necessary and sufficient condition for the optimality of a Bayesian estimator. Loosely stated, the orthogonality principle says that the error vector of the optimal estimator (in a mean square error sense) is orthogonal to any possible estimator. The orthogonality principle is most commonly stated for linear estimators, but more general formulations are possible. Since the principle is a necessary and sufficient condition for optimality, it can be used to find the minimum mean square error estimator.

Orthogonality principle for linear estimators[edit]

The orthogonality principle is most commonly used in the setting of linear estimation.^[1] In this context, let x be an unknown random vector which is to be estimated based on the observation vector y. One wishes to construct a linear estimator ${\hat {x}}=Hy+c$ for some matrix H and vector c. Then, the orthogonality principle states that an estimator ${\hat {x}}$ achieves minimum mean square error if and only if

If x and y have zero mean, then it suffices to require the first condition.

Example[edit]

Suppose x is a Gaussian random variable with mean m and variance $\sigma _{x}^{2}.$ Also suppose we observe a value y=x+w, where w is Gaussian noise which is independent of x and has mean 0 and variance $\sigma _{w}^{2}.$ We wish to find a linear estimator ${\hat {x}}=hy+c$ minimizing the MSE. Substituting the expression ${\hat {x}}=hy+c$ into the two requirements of the orthogonality principle, we obtain

$0=\operatorname {E} \{({\hat {x}}-x)y\}$

$0=\operatorname {E} \{(hx+hw+c-x)(x+w)\}$

$0=h(\sigma _{x}^{2}+\sigma _{w}^{2})+hm^{2}+cm-\sigma _{x}^{2}-m^{2}$

and

$0=\operatorname {E} \{{\hat {x}}-x\}$

$0=\operatorname {E} \{hx+hw+c-x\}$

Solving these two linear equations for h and c results in

$h = \frac{\sigma_x^2}{\sigma_x^2 +\sigma_w^2}, \quad c = \frac{\sigma_w^2}{\sigma_x^2+\sigma_w^2} m ,$

so that the linear minimum mean square error estimator is given by

$\hat{x} = \frac{\sigma_x^2}{\sigma_x^2 +\sigma_w^2} y + \frac{\sigma_w^2}{\sigma_x^2 +\sigma_w^2} m.$

This estimator can be interpreted as a weighted average between the noisy measurements y and the prior expected value m. If the noise variance $\sigma _{w}^{2}$ is low compared with the variance of the prior $\sigma _{x}^{2}$ (corresponding to a high SNR), then most of the weight is given to the measurements y, which are deemed more reliable than the prior information. Conversely, if the noise variance is relatively higher, then the estimate will be close to m, as the measurements are not reliable enough to outweigh the prior information.

Finally, note that because the variables x and y are jointly Gaussian, the minimum MSE estimator is linear.^[2] Therefore, in this case, the estimator above minimizes the MSE among all estimators, not only linear estimators.

General formulation[edit]

Let be a Hilbert space of random variables with an inner product defined by $\langle x,y\rangle =\operatorname {E} \{x^{H}y\}$ . Suppose is a closed subspace of , representing the space of all possible estimators. One wishes to find a vector ${\hat {x}}\in W$ which will approximate a vector $x\in V$ . More accurately, one would like to minimize the mean squared error (MSE) $\operatorname {E} \|x-{\hat {x}}\|^{2}$ between ${\hat {x}}$ and .

In the special case of linear estimators described above, the space is the set of all functions of and , while is the set of linear estimators, i.e., linear functions of only. Other settings which can be formulated in this way include the subspace of causal linear filters and the subspace of all (possibly nonlinear) estimators.

Geometrically, we can see this problem by the following simple case where is a one-dimensional subspace:

We want to find the closest approximation to the vector by a vector ${\hat {x}}$ in the space . From the geometric interpretation, it is intuitive that the best approximation, or smallest error, occurs when the error vector, , is orthogonal to vectors in the space .

More accurately, the general orthogonality principle states the following: Given a closed subspace of estimators within a Hilbert space and an element in , an element ${\hat {x}}\in W$ achieves minimum MSE among all elements in if and only if $\operatorname {E} \{(x-{\hat {x}})y^{T}\}=0$ for all $y\in W.$

Stated in such a manner, this principle is simply a statement of the Hilbert projection theorem. Nevertheless, the extensive use of this result in signal processing has resulted in the name «orthogonality principle.»

A solution to error minimization problems[edit]

The following is one way to find the minimum mean square error estimator by using the orthogonality principle.

We want to be able to approximate a vector by

$x={\hat {x}}+e\,$

where

${\hat {x}}=\sum _{i}c_{{i}}p_{{i}}$

is the approximation of as a linear combination of vectors in the subspace spanned by $p_{{1}},p_{{2}},\ldots .$ Therefore, we want to be able to solve for the coefficients, $c_{i}$ , so that we may write our approximation in known terms.

By the orthogonality theorem, the square norm of the error vector, $\left\Vert e\right\Vert ^{{2}}$ , is minimized when, for all j,

$\left\langle x-\sum _{i}c_{{i}}p_{{i}},p_{{j}}\right\rangle =0.$

Developing this equation, we obtain

$\left\langle x,p_{{j}}\right\rangle =\left\langle \sum _{i}c_{{i}}p_{{i}},p_{{j}}\right\rangle =\sum _{i}c_{{i}}\left\langle p_{{i}},p_{{j}}\right\rangle .$

If there is a finite number of vectors $p_{i}$ , one can write this equation in matrix form as

${\begin{bmatrix}\left\langle x,p_{{1}}\right\rangle \\\left\langle x,p_{{2}}\right\rangle \\\vdots \\\left\langle x,p_{{n}}\right\rangle \end{bmatrix}}={\begin{bmatrix}\left\langle p_{{1}},p_{{1}}\right\rangle &\left\langle p_{{2}},p_{{1}}\right\rangle &\cdots &\left\langle p_{{n}},p_{{1}}\right\rangle \\\left\langle p_{{1}},p_{{2}}\right\rangle &\left\langle p_{{2}},p_{{2}}\right\rangle &\cdots &\left\langle p_{{n}},p_{{2}}\right\rangle \\\vdots &\vdots &\ddots &\vdots \\\left\langle p_{{1}},p_{{n}}\right\rangle &\left\langle p_{{2}},p_{{n}}\right\rangle &\cdots &\left\langle p_{{n}},p_{{n}}\right\rangle \end{bmatrix}}{\begin{bmatrix}c_{{1}}\\c_{{2}}\\\vdots \\c_{{n}}\end{bmatrix}}.$

Assuming the $p_{i}$ are linearly independent, the Gramian matrix can be inverted to obtain

${\begin{bmatrix}c_{{1}}\\c_{{2}}\\\vdots \\c_{{n}}\end{bmatrix}}={\begin{bmatrix}\left\langle p_{{1}},p_{{1}}\right\rangle &\left\langle p_{{2}},p_{{1}}\right\rangle &\cdots &\left\langle p_{{n}},p_{{1}}\right\rangle \\\left\langle p_{{1}},p_{{2}}\right\rangle &\left\langle p_{{2}},p_{{2}}\right\rangle &\cdots &\left\langle p_{{n}},p_{{2}}\right\rangle \\\vdots &\vdots &\ddots &\vdots \\\left\langle p_{{1}},p_{{n}}\right\rangle &\left\langle p_{{2}},p_{{n}}\right\rangle &\cdots &\left\langle p_{{n}},p_{{n}}\right\rangle \end{bmatrix}}^{{-1}}{\begin{bmatrix}\left\langle x,p_{{1}}\right\rangle \\\left\langle x,p_{{2}}\right\rangle \\\vdots \\\left\langle x,p_{{n}}\right\rangle \end{bmatrix}},$

thus providing an expression for the coefficients $c_{i}$ of the minimum mean square error estimator.

Notes[edit]

^ Kay, p.386
^ See the article minimum mean square error.

References[edit]

Kay, S. M. (1993). Fundamentals of Statistical Signal Processing: Estimation Theory. Prentice Hall. ISBN 0-13-042268-1.
Moon, Todd K. (2000). Mathematical Methods and Algorithms for Signal Processing. Prentice-Hall. ISBN 0-201-36186-8.

Источник

В статистика и обработка сигналов, то принцип ортогональности является необходимым и достаточным условием оптимальности Байесовская оценка. В общих чертах принцип ортогональности говорит, что вектор ошибок оптимальной оценки (в среднеквадратичная ошибка смысл) ортогонален любой возможной оценке. Принцип ортогональности чаще всего формулируется для линейных оценок, но возможны и более общие формулировки. Поскольку принцип является необходимым и достаточным условием оптимальности, его можно использовать для нахождения минимальная среднеквадратичная ошибка оценщик.

Принцип ортогональности для линейных оценок

Принцип ортогональности чаще всего используется при линейной оценке.^[1] В этом контексте пусть Икс быть неизвестным случайный вектор который должен быть оценен на основе вектора наблюдения у. Хочется построить линейную оценку для какой-то матрицы ЧАС и вектор c. Тогда принцип ортогональности гласит, что оценка достигает минимальная среднеквадратичная ошибка если и только если

Если Икс и у имеют нулевое среднее значение, тогда достаточно потребовать первого условия.

Пример

Предполагать Икс это Гауссовская случайная величина со средним м и дисперсия $сигма _ {x} ^ {2}.$ Также предположим, что мы наблюдаем значение куда ш гауссов шум, не зависящий от Икс и имеет среднее значение 0 и дисперсию $сигма _ {w} ^ {2}.$ Мы хотим найти линейную оценку минимизация MSE. Подставляя выражение в два требования принципа ортогональности, получаем

{displaystyle 0 = operatorname {E} {({hat {x}} - x) y}}

{displaystyle 0 = operatorname {E} {(hx + hw + c-x) (x + w)}}

${displaystyle 0 = h (sigma _ {x} ^ {2} + sigma _ {w} ^ {2}) + hm ^ {2} + cm-sigma _ {x} ^ {2} -m ^ {2} }$

{displaystyle 0 = operatorname {E} {{hat {x}} - x}}

{displaystyle 0 = operatorname {E} {hx + hw + c-x}}

Решая эти два линейных уравнения относительно час и c приводит к

$h = frac {sigma_x ^ 2} {sigma_x ^ 2 + sigma_w ^ 2}, quad c = frac {sigma_w ^ 2} {sigma_x ^ 2 + sigma_w ^ 2} m,$

так что линейная оценка минимальной среднеквадратичной ошибки задается

$шляпа {x} = frac {sigma_x ^ 2} {sigma_x ^ 2 + sigma_w ^ 2} y + frac {sigma_w ^ 2} {sigma_x ^ 2 + sigma_w ^ 2} m.$

Эту оценку можно интерпретировать как средневзвешенное значение измерений зашумленных измерений. у и предыдущее ожидаемое значение м. Если дисперсия шума $сигма _ {ш} ^ {2}$ низка по сравнению с дисперсией предыдущего $сигма _ {x} ^ {2}$ (соответствует высокому SNR ), то большая часть веса приходится на измерения у, которые считаются более надежными, чем предыдущая информация. И наоборот, если дисперсия шума относительно выше, то оценка будет близка к м, поскольку измерения недостаточно надежны, чтобы перевесить предварительную информацию.

Наконец, обратите внимание, что поскольку переменные Икс и у вместе являются гауссовыми, оценка минимальной MSE линейна.^[2] Следовательно, в этом случае описанный выше оценщик минимизирует MSE среди всех оценщиков, а не только для линейных оценщиков.

Общая формулировка

Позволять быть Гильбертово пространство случайных величин с внутренний продукт определяется ${displaystyle langle x, yangle = имя оператора {E} {x ^ {H} y}}$ . Предполагать это закрыто подпространство , представляющий пространство всех возможных оценок. Хочется найти вектор который аппроксимирует вектор xin V . Точнее, хотелось бы минимизировать среднеквадратичную ошибку (MSE). ${displaystyle operatorname {E} | x- {шляпа {x}} | ^ {2}}$ между и Икс .

В частном случае линейных оценок, описанном выше, пространство это набор всех функций Икс и , пока — множество линейных оценок, т. е. линейных функций от Только. Другие параметры, которые можно сформулировать таким образом, включают подпространство причинный линейные фильтры и подпространство всех (возможно, нелинейных) оценок.

Геометрически мы можем увидеть эту проблему в следующем простом случае, когда это одномерный подпространство:

Мы хотим найти наиболее близкое приближение к вектору Икс вектором в пространстве . Из геометрической интерпретации интуитивно понятно, что наилучшее приближение или наименьшая ошибка возникает, когда вектор ошибки , ортогональна векторам в пространстве .

Точнее, общий принцип ортогональности утверждает следующее: для замкнутого подпространства оценок в гильбертовом пространстве и элемент Икс в , элемент достигает минимальной MSE среди всех элементов в если и только если ${displaystyle operatorname {E} {(x- {hat {x}}) y ^ {T}} = 0}$ для всех

Сформулированный таким образом, этот принцип является просто утверждением Теорема проекции Гильберта. Тем не менее, широкое использование этого результата в обработке сигналов привело к названию «принцип ортогональности».

Решение проблем минимизации ошибок

Ниже приводится один из способов найти минимальная среднеквадратичная ошибка оценка с использованием принципа ортогональности.

Мы хотим иметь возможность аппроксимировать вектор Икс к

куда

${шляпа {x}} = сумма _ {i} c _ {{i}} p _ {{i}}$

это приближение Икс как линейная комбинация векторов из подпространства охватывает $p _ {{1}}, p _ {{2}}, ldots.$ Поэтому мы хотим иметь возможность найти коэффициенты, $c_ {i}$ , так что мы можем записать наше приближение в известных терминах.

По теореме ортогональности квадратная норма вектора ошибки, $leftVert восемьVert ^ {{2}}$ , минимизируется, когда для всех j,

$leftlangle x-sum _ {i} c _ {{i}} p _ {{i}}, p _ {{j}} ightangle = 0.$

Развивая это уравнение, получаем

$leftlangle x, p _ {{j}} ightangle = leftlangle sum _ {i} c _ {{i}} p _ {{i}}, p _ {j}} ightangle = sum _ {i} c _ {{i}} leftlangle p _ {{i}}, p _ {{j}} igangle.$

Если есть конечное число векторов , можно записать это уравнение в матричной форме как

${egin {bmatrix} leftlangle x, p _ {{1}} ightangle leftlangle x, p _ {{2}} ightangle vdots leftlangle x, p _ {{n}} ightangle end {bmatrix}} = {egin {bmatrix} leftlangle p _ {{1}}, p _ {{1}} ightangle & leftlangle p _ {{2}}, p _ {{1}} ightangle & cdots & leftlangle p _ {{n}}, p _ {{1}} ightangle leftlangle p_ { {1}}, p _ {{2}} ightangle & leftlangle p _ {{2}}, p _ {{2}} ightangle & cdots & leftlangle p _ {{n}}, p _ {2}} ightangle vdots & vdots & ddots & vdots leftlangle p _ {{1}}, p _ {{n}} ightangle & leftlangle p _ {{2}}, p _ {{n}} ightangle & cdots & leftlangle p _ {{n}}, p _ {{n}} ightangle end {bmatrix}} {egin {bmatrix} c _ {{1}} c _ {{2}} vdots c _ {{n}} end {bmatrix}}.$

Если предположить находятся линейно независимый, то Матрица грамиана можно инвертировать, чтобы получить

${egin {bmatrix} c _ {{1}} c _ {{2}} vdots c _ {{n}} end {bmatrix}} = {egin {bmatrix} leftlangle p _ {{1}}, p _ {{1 }} ightangle & leftlangle p _ {{2}}, p _ {1}} ightangle & cdots & leftlangle p _ {{n}}, p _ {{1}} ightangle leftlangle p _ {{1}}, p _ {{2}} ightangle & leftlangle p _ {{2}}, p _ {{2}} ightangle & cdots & leftlangle p _ {{n}}, p _ {2}} ightangle vdots & vdots & ddots & vdots leftlangle p _ {{1}}, p _ {{n} } ightangle & leftlangle p _ {{2}}, p _ {{n}} ightangle & cdots & leftlangle p _ {{n}}, p _ {{n}} ightangle end {bmatrix}} ^ {{- 1}} {egin {bmatrix} leftlangle x, p _ {{1}} ightangle leftlangle x, p _ {{2}} ightangle vdots leftlangle x, p _ {{n}} ightangle end {bmatrix}},$

таким образом давая выражение для коэффициентов $c_ {i}$ оценщика минимальной среднеквадратичной ошибки.

Смотрите также

Минимальная среднеквадратичная ошибка
Теорема проекции Гильберта

Примечания

^ Кей, стр.386
^ См. Статью минимальная среднеквадратичная ошибка.

Что такое ортогональность?[править]

Термин «ортогональность» заимствован из геометрии. Две линии являются ортогональными, если они пересекаются под прямым углом, например, оси координат на графике. В терминах векторной алгебры две такие линии перемещения являются независимыми. Если двигаться параллельно оси X вдоль одной из линий, то проекция движущейся точки на другую линию не меняется. Этот термин был введен в информатике для обозначения некой разновидности независимости или несвязанности. В грамотно спроектированной системе программа базы данных будет ортогональной к интерфейсу пользователя: вы можете менять интерфейс пользователя без воздействия на базу данных и менять местами базы данных, не меняя интерфейса. Перед тем как рассмотреть преимущества ортогональных систем, познакомимся с неортогональной системой.

Неортогональная система[править]

Предположим, вы находитесь в экскурсионном вертолете, совершающем полет над Гранд-Каньоном, когда пилот, который совершил ошибку, наевшись рыбы за обедом внезапно вскрикивает и теряет сознание. По счастливой случайности это происходит, когда вы парите на высоте 30 метров. Вы догадываетесь, что рычаг управления общим шагом несущего винта обеспечивает подъем машины, так что, если его слегка опустить, вертолет начнет плавно снижаться. Однако когда вы пытаетесь сделать это, то осознаете, что жизнь — не такая уж простая штука. Вертолет клюет носом, и вас начинает вращать по спирали влево. Внезапно вы понимаете, что управляете системой, в которой каждое воздействие имеет побочные эффекты. При нажатии на левый рычаг вам придется сделать уравновешивающее движение назад правым рычагом и нажать на правую педаль. Но при этом каждое из этих действий вновь повлияет на все органы управления. Неожиданно вам приходится жонглировать невероятно сложной системой, в которой любое изменение влияет на все остальные управляющие воздействия. Вы испытываете феноменальную нагрузку: ваши руки и ноги находятся в постоянном движении, пытаясь уравновесить все взаимодействующие силы. Органы управления вертолетом определенно не являются ортогональными.

Преимущества ортогональности[править]

Как показывает пример с вертолетом, неортогональные системы сложнее изменять и контролировать. Если составляющие системы отличаются высокой степенью взаимозависимости, то невозможно устранить какую-либо неисправность лишь на локальном уровне.

Исключайте взаимодействие между объектами, не относящимися друг к другу

Мы хотим спроектировать компоненты, которые являются самодостаточным независимыми, с единственным, четким назначением. Когда компоненты изолированы друг от друга, вы уверены, что можно изменить один из них, не заботясь об остальных. Пока внешние интерфейсы этого компонента остаются неизменными можете быть спокойны, что не создадите проблем, которые распространятся по ВСЕЙ системе. С созданием ортогональных систем у вас появятся два больших преимущества: увеличение производительности и снижение риска.

Увеличение производительности[править]

Изменения в системе локализуются, поэтому периоды разработки и тестирования сократятся. Легче написать относительно небольшие, самодостаточные компоненты, чем один большой программный модуль. Простые компоненты могут быть спроектированы, запрограммированы, протестированы и затем забыты — не нужно непрерывно менять существующий текст по мере того, как к нему добавляются новые фрагменты.
Ортогональный подход также способствует многократному использованию компонентов. Если компоненты имеют определенную, четкую сферу ответственности, они могут комбинироваться с новыми компонентами способами, которые не предполагались при их первоначальной реализации. Чем меньше связанность в системах, тем легче их перенастроить и провести их обратное проектирование.
При комбинировании ортогональных компонентов происходит заметное увеличение производительности. Предположим, что один компонент способен осуществлять М, а второй — N различных операций. Если эти компоненты ортогональны и комбинируются, то в сумме они способны осуществить MxN различных операций. Но если два компонента не являются ортогональными, они будут перекрываться, и результат их действия будет меньшим по сравнении с ортогональными компонентами. Вы получаете большее количество функциональных возможностей в пересчете на единичное усилие, если комбинируете между собой ортогональные компоненты.

Снижение риска[править]

Ортогональный подход приводит к снижению уровня риска, присущего любой разработке.

Ошибочные фрагменты текста программы изолируются. Если модуль содержит ошибку, то вероятность ее распространения на всю систему уменьшается. Кроме того, ошибочный фрагмент может быть извлечен и заменен новым (исправленным).
Конечный продукт (система) становится менее хрупким. Проблемы, появляющиеся при внесении небольших изменений и устранении недочетов на определенном участке, не проходят дальше этого участка.
Ортогональная система способствует повышению качества тестирования, поскольку облегчается проектирование и тестирование отдельных ее компонентов.
Вы не будете слишком сильно привязаны к определенному субподрядчику, программному продукту или платформе, поскольку интерфейсы между компонентами, производимыми фирмами-субподрядчиками, не будут играть главенствующей роли в проекте.

Рассмотрим некоторые из способов, при помощи которых вы сможете внедрить принцип ортогональности в вашу работу.

Проектные группы[править]

Приходилось ли вам замечать, насколько эффективно работают проектные команды, все члены которых знают, что делать, и полностью отдают себя делу, тогда как в других командах сотрудники постоянно препираются между собой и не собираются ни в чем уступать друг другу? Зачастую это не что иное, как проблема ортогональности. Если команды организованы с большим числом перекрытий, то сотрудники путают свои должностные обязанности. Для любого изменения необходимо собирать всю команду, поскольку оно, может быть, затронет каждого. Как разбить команду на группы с четкими обязанностями и минимальным перекрытием? На этот вопрос нет простого ответа. В некоторой степени это зависит от проекта и вашего анализа областей, которые в перспективе могут измениться. Это же зависит от людей, находящихся в вашем распоряжении. Мы предпочитаем отделять инфраструктуру от приложения. Каждому из основных инфраструктурных компонентов (база данных, интерфейс связи, промежуточное программное обеспечение и т.д.) приписывается только ему принадлежащая группа. Подобным образом производится разделение функциональных возможностей приложения. После этого мы изучаем людей, которые имеются в нашем распоряжении на данный момент (или их появление в будущем), и сообразно этому корректируем состав групп. Вы можете неформально определить уровень ортогональности структуры проектной команды. Для этого просто посмотрите, скольких людей нужно привлечь к обсуждению каждого изменения, требуемого со стороны. Чем больше эта цифра, тем ниже уровень ортогональности группы. Отсюда ясно, что ортогональная команда работает более эффективно. (Высказав это, мы тем самым поощряем стремление сотрудников более мелких подразделений постоянно общаться друг с другом.)

Проектирование[править]

Большинство разработчиков знакомо с потребностью в проектировании ортогональных систем, хотя они наверняка используют термины «модульный», «компонентно-ориентированный» и «многоуровневый» для описания конкретного процесса. Системы должны быть скомпонованы из набора взаимодействующих модулей каждый из которых реализует функциональные возможности независимо от других. Иногда эти компоненты объединены в уровни, каждый из которых обеспечивает некий уровень абстракции. Данный многоуровневый подход является мощным методом проектирования ортогональных систем. Поскольку на каждом уровне используются только абстракции, обеспеченные на низших уровнях, можно легко изменить основные реализации, не затрагивая самой программы. Иерархическое представление также уменьшает риск появления неконтролируемых зависимостей между модулями. Существует простой тест на ортогональность проектирования. Как только вы составили схему компонентов, спросите себя: «Сколько модулей подвергнутся воздействию, если я резко изменю требования по конкретной функции?» В ортогональной системе ответ должен быть «один». Перемещение кнопки на панели графического интерфейса пользователя не должно требовать внесения изменений в схему базы данных. Добавление контекстно-зависимой справки не должно изменить подсистему выставления счетов. Рассмотрим сложную систему контроля и управления отопительной установкой. Первоначально требовалось наличие графического интерфейса, но затем требования были изменены, с тем чтобы добавить систему речевого ответа и управления установкой при помощи телефона с тональным набором. В ортогонально спроектированной системе для этого вам пришлось бы изменить только модули, связанные с интерфейсом пользователя, а основная логика управления предприятием остается неизменной. На самом деле, если вы тщательно структурируете систему, то у вас должна быть возможность поддержки обоих интерфейсов при наличии одной и той же программной базы. Стоит спросить себя, как защитить вашу конструкцию от изменений в окружающем мире, например, вы пользуетесь номером телефона в качестве идентификатора заказчика. Что произойдет, если телефонная станция изменит коды междугородней связи? Не полагайтесь на свойства предметов, которыми не можете управлять.

Инструментарии и библиотеки[править]

Будьте внимательным, чтобы сохранить ортогональность вашей системы при введении инструментариев и библиотек, произведенных фирмами-субподрядчиками. Проявите мудрость при выборе технологии. Однажды авторы работали над проектом, в котором требовалось, чтобы некий фрагмент программы на языке Java выполнялся автономно — на сервере и в удаленном режиме — на клиентской машине. В этом случае возможными вариантами распределения классов были технологии RMI и CORBA. Если удаленный доступ к классу обеспечивался при помощи RMI, то в этом случае каждое обращение к удаленному методу в этом классе могло бы привести к генерации исключения, означающей, что эта наивная реализация потребовала бы от нас обработки этого исключения всякий раз при использовании удаленных классов. В данном случае использование RMI явно не ортогонально: программа, обращающаяся к удаленным классам, не должна зависеть от их физического расположения. Альтернативный способ — технология CORBA — не налагает подобного ограничения: мы можем написать программу, для которой не имеет значения, где физически находятся классы. Когда вы используете инструментарий (или даже библиотеку, созданную другими разработчиками), вначале спросите себя, не заставит ли он внести в вашу программу изменения, которых там быть не должно. Если схема долговременного хранения объекта прозрачна, то она ортогональна. Если же при этом требуется создание объектов или обращение к ним каким-либо особым образом, то она неортогональна. Отделение этих подробностей от вашей программы дает дополнительное преимущество, связанное с возможностью смены субподрядчиков в будущем. Интересным примером ортогональности является система Enterprise Java Beans. В большинстве диалоговых систем обработки запросов прикладная программа должна обозначать начало и окончание каждой транзакции. В системе EJB эта информация выражена описательно в виде метаданных вне любых программ. Та же прикладная программа может работать в различных транзакционных средах без каких-либо изменений. Вероятно, это станет прообразом многих операционных сред будущего. Другой интересной проверкой на ортогональность является технология Aspect Oriented Programming — исследовательский проект фирмы Xerox Parc. Технология АОР позволяет выразить в одном-единственном месте линию поведения, которая в противном случае была бы распределена по всему исходному тексту программы. Например, журнальные сообщения обычно генерируются путем явных обращений к некоторой функции записи в журнал по всему исходному тексту. Используя технологию АОР, вы реализуете процедуру записи в журнал ортогонально к записываемым данным. Используя версию АОР для языка Java можно записать сообщение журнала при входе в любой метод класса Fred, запрограммировав аспект:

aspect Trace { advise * Fred.*(..) { static before { Log.write("-> Entering + thisJoinPoint.methodName); }}}

При вплетении этого аспекта в текст вашей программы будут генерироваться трассировочные сообщения. Если этого не сделать, не будет и сообщений. В обоих случаях исходный текст остается неизменным.

Написание текста программы[править]

Всякий раз, когда вы пишете программу, вы подвергаетесь риску снижения уровня ортогональности вашего приложения. Если вы постоянно не отслеживаете не только то, что вы делаете, но и весь контекст приложения, то существует опасность неумышленного дублирования функциональных возможностей в некотором другом модуле или выражения существующих знаний дважды. Есть ряд методик, которые можно использовать для поддержки ортогональности:

Сохраните вашу программу «несвязанной». Напишите «скромную» программу — модули, которые не раскрывают ничего лишнего для других модулей и не полагаются на их внедрение. Попробуйте применить закон Деметера , который обсуждается в разделе «Несвязанности и закон Деметера». При надобности изменения состояния объекта это должен делать сам объект. В таком случае программа остается изолированной от реализации другой программы, а вероятность того, что система останется ортогональной, увеличивается.
Избегайте глобальных данных. Всякий раз, когда ваша программа ссылается на глобальные данные, она привязывается к другим компонентам, использующим эти данные. Даже глобальные переменные, которые вы собираетесь использовать только для чтения, могут вызвать проблемы (например, если вам нужно срочно изменить программу, сделав ее многопоточной). Вообще программа станет проще в понимании и сопровождении, если вы явно перешлете любой требуемый контекст в ваши модули. В объектно-ориентированных приложениях контекст часто пересылается в виде параметра в конструктор объектов. В другой программе вы можете создать конструкции, содержащие контекст, и обходить ссылки на них.
Подобные функции. Зачастую вы сталкиваетесь с набором функций, похожих друг на друга; возможно, они используют общий фрагмент в начале и конце программы, но в ее середине каждая пользуется своим алгоритмом. Дублированная программа является признаком структурных проблем. Для того чтобы составить программу лучше, следует обратить внимание на шаблон Strategy в книге «Design Patterns».

Пусть постоянное критическое отношение к вашей программе войдет у вас в привычку. Ищите любые возможности реорганизации для усовершенствования ее конструкции и повышения уровня ортогональности. Этот процесс называется реорганизацией.

Тестирование[править]

Систему, спроектированную и реализованную ортогональным образом, намного проще тестировать. Поскольку взаимодействие между компонентами системы формализовано и ограничено, большая часть тестирования может осуществляться на уровне отдельных модулей. Это хорошо, поскольку подобное тестирование значительно легче поддается спецификации и выполнению, чем интеграционное тестирование. Мы предлагаем, чтобы каждый модуль был снабжен своим собственным встроенным тестом, и эти тесты выполнялись автоматически как часть обычной процедуры сборки. Процедура сборки модульного теста сама по себе является интересным тестом на ортогональность. Что требуется, чтобы собрать и скомпоновать тест модуля? Должны ли вы задействовать большую часть системы только для того, чтобы скомпилировать или скомпоновать тест? В этом случае модуль очень хорошо связан с оставшейся частью системы. Момент устранения ошибки также подходит для оценки ортогональности системы в целом. Когда вы сталкиваетесь с проблемой, оцените, насколько локален процесс ее устранения. Нужно изменить лишь один модуль, или изменения должны происходить по всей системе? Когда вы меняете что-либо, устраняются ли при этом ошибки или происходит загадочное появление новых? Это удачный момент для внедрения автоматизации. Если вы применяете систему управления исходным текстом, комментируйте устранение ошибок, когда вы осуществляете возвращение модуля в библиотеку после тестирования. Затем вы можете генерировать ежемесячные отчеты, где анализируются тенденции в ряде исходных файлов, в которых производилось устранение ошибок.

Документация[править]

Что удивительно, ортогональность применима и к документации. Координатами являются содержание и представление. Если документация действительно ортогональна, вы можете существенно изменить внешний вид, не изменяя содержания. Современные текстовые процессоры содержат стили и макрокоманды, которые помогают в этом.

Жизнь в условиях ортогональности[править]

Ортогональность тесно связана с принципом DRY (анг. «don’t repeat yourself» — «нe повторяй самого себя»).
DRY — это базовый принцип заявленный в книге
«Программист-прагматик» Эндрю Ханта и Дэйва Томаса (The Pragmatic Programmer).
Авторы расматривали этот принцип в контексте баз данных, тестовых планов, проектирования программных систем,
а также документирования систем^[1]
Используя этот принцип, можно свести к минимуму дублирование в пределах системы, а при помощи ортогональности уменьшить взаимозависимость между компонентами системы.

Звучит неуклюже, но если вы используете принцип ортогональности в тесной связи с принципом DRY, вы обнаружите, что разрабатываемые вами системы становятся более гибкими, более понятными и более простыми в отладке, тестировании и сопровождении. Когда вы присоединяетесь к проекту, в котором люди ведут отчаянную борьбу за внесение изменений, а каждое изменение приводит к появлению четырех новых проблем, вспомните кошмар с вертолетом. Вероятно, проект сконструирован и запрограммирован неортогонально.

↑ Dave Thomas, interviewed by Bill Venners Orthogonality and the DRY Principle Проверено 2006-12-01 г.